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
5 changes: 2 additions & 3 deletions draft-ietf-quic-recovery.md
View file
Open in desktop
Expand Up @@ -229,9 +229,8 @@ 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 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
greater than the largest received packet number. A receiver MAY immediately
ack subsequent packets after first receiving a packet out of order. 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
after a single packet loss.
Expand Down