Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Send an immediate ACK #2025

Merged
merged 16 commits into from Feb 1, 2019
Merged

Send an immediate ACK #2025

Changes from 1 commit
Commits
Show all changes
16 commits
Select commit Hold shift + click to select a range
249f152
Send a few immediate ACKs
ianswett Nov 20, 2018
099dedd
Update draft-ietf-quic-recovery.md
ianswett Nov 20, 2018
31d1343
Merge branch 'master' into ianswett-immediate-ack
ianswett Jan 11, 2019
b343e2b
Update draft-ietf-quic-recovery.md
ianswett Jan 11, 2019
f070e8f
Should immediately ACK one packet
ianswett Jan 15, 2019
60a6255
Update draft-ietf-quic-recovery.md
ianswett Jan 15, 2019
cfb0ae8
Update draft-ietf-quic-recovery.md
ianswett Jan 15, 2019
183d6c3
Update draft-ietf-quic-recovery.md
ianswett Jan 15, 2019
87ac16a
Update draft-ietf-quic-recovery.md
ianswett Jan 15, 2019
fba23ef
Update draft-ietf-quic-recovery.md
ianswett Jan 15, 2019
ac2c595
Update draft-ietf-quic-recovery.md
ianswett Jan 15, 2019
741c294
Jana's suggestion
ianswett Jan 29, 2019
7e473d9
Only send immediate acks for 1/8 RTT
ianswett Jan 29, 2019
8b7cb1a
A bit clearer
ianswett Jan 30, 2019
2c9832b
Update draft-ietf-quic-recovery.md
ianswett Jan 30, 2019
d5cb783
Update draft-ietf-quic-recovery.md
ianswett Jan 30, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
24 changes: 11 additions & 13 deletions draft-ietf-quic-recovery.md
View file
Open in desktop
Expand Up @@ -224,11 +224,16 @@ the peer spurious timeouts. The maximum ack delay is communicated in the
An acknowledgement SHOULD be sent immediately upon receipt of a second
packet but the delay SHOULD NOT exceed the maximum ack delay. QUIC recovery
algorithms do not assume the peer generates an acknowledgement immediately when
receiving a second full-packet.
receiving a second packet.

Out-of-order packets SHOULD be acknowledged more quickly, in order to accelerate
loss recovery. The receiver SHOULD send an immediate ACK when it receives a new
packet which is not one greater than the largest received packet number.
packet which is not the next expected one. That is, its packet number is not one
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, there are SHOULDs on top of SHOULDs here. How about this for a paragraph:

"Quicker acknowledgement of out-of-order packets may accelerate loss detection. Upon receipt of a packet number not one more than the previous maximum received, receivers SHOULD separately acknowledge it and the next few packets, but not more than five."

This is shorter, has only one SHOULD, and places a recommended limit that is less subjective than "a few".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we have a reordering threshold constant we could use here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the suggestions, I reworked the text to only have one SHOULD and mention the 1/8 RTT as the max amount of time to send immediate acks.

greater than the largest received packet number. A receiver SHOULD immediately
ack at least three subsequent packets after first receiving a packet out of
order, after which it SHOULD resume delaying acknowledgements. A receiver
SHOULD NOT send an immediate ACK any time there is a gap in the ACK frame,
ianswett marked this conversation as resolved.
Show resolved Hide resolved
because that will cause it to send an ACK for every packet for at least an RTT.

Similarly, packets marked with the ECN Congestion Experienced (CE) codepoint in
the IP header SHOULD be acknowledged immediately, to reduce the peer's response
Expand Down Expand Up @@ -477,18 +482,11 @@ sender might choose to optimize this by setting the timer fewer times if it
knows that more ack-eliciting packets will be sent within a short period of
time.

An acknowledgement SHOULD be sent immediately upon receipt of a second
packet but the delay SHOULD NOT exceed the maximum ack delay. QUIC recovery
algorithms do not assume the peer generates an acknowledgement immediately when
receiving a second packet.
#### Sending Probe Packets

Out-of-order packets SHOULD be acknowledged more quickly, in order to accelerate
loss recovery. The receiver SHOULD send an immediate ACK when it receives a new
packet which is not one greater than the largest received packet number. The
receiver MAY send an immediate ACK when a missing packet begins exceeding the
peer's reordering threshold in packets to accelerate fast retransmit. Time
threshold loss detection does not require any special ACK generation to
accelerate fast retransmit, because it uses a timer.
When a PTO timer expires, the sender MUST send one ack-eliciting packet as a
probe. A sender MAY send up to two ack-eliciting packets, to avoid an expensive
consecutive PTO expiration due to a single packet loss.

Consecutive PTO periods increase exponentially, and as a result, connection
recovery latency increases exponentially as packets continue to be dropped in
Expand Down
You are viewing a condensed version of this merge commit. You can view the full changes here.