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

Only send one immediate ACK #3361

Merged
merged 3 commits into from
Mar 22, 2020
Merged

Only send one immediate ACK #3361

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
b214465
Only send one immediate ACK
ianswett Jan 17, 2020
0a2fed9
MUST -> SHOULD
ianswett Jan 18, 2020
5af33e5
Kazuho's suggestion
ianswett Jan 18, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 4 additions & 6 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3136,12 +3136,10 @@ This recommendation is in keeping with standard practice for TCP {{?RFC5681}}.

In order to assist loss detection at the sender, an endpoint SHOULD send an ACK
frame immediately on receiving an ack-eliciting packet that is out of order. The
Copy link
Member

Choose a reason for hiding this comment

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

We still need to know what "out of order" means. I presume that this is "when an ack-eliciting packet arrives with a packet number that more than one greater than any previously received packet" or something like that.

Copy link
Member

@kazuho kazuho Jan 20, 2020 •
edited
Loading

Choose a reason for hiding this comment

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

Agreed. I think that's the definition we are looking for to close #3347, though I am now beginning to wonder if we need "ack-eliciting" within the condition.

Shouldn't receiving a packet with a PN gap, regardless of the packet being ACK-eliciting or not, trigger an immediate ACK? (Striked, as I think doing so might cause infinite ping-pong).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I should have moved the definition from the recovery draft when the ACK text was moved.

I believe moving text is an editorial change, so how about I do that in a separate PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

#3369

Copy link
Contributor

Choose a reason for hiding this comment

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

@martinthomson Not sure about "when an ack-eliciting packet arrives with a packet number that more than one greater than any previously received packet". If a delayed packet has been received, would not you want to notify the other endpoint ASAP, in case it did not retransmit the data, yet?

I'd think "out of order" means "any packet with a packet number other than one greater then the largest previously received packet number". (Or, optimizing a bit, "any ack-eliciting packet with a packet number other than one greater then the largest previously received packet number, or a non-ack-eliciting packet with a packet number more than one greater then the largest previously received packet number".)

endpoint MAY continue sending ACK frames immediately on each subsequently
received packet, but the endpoint SHOULD return to acknowledging every other
packet within a period of 1/8 x RTT, unless more ack-eliciting packets are
received out of order. If every subsequent ack-eliciting packet arrives out of
order, then an ACK frame SHOULD be sent immediately for every received
ack-eliciting packet.
endpoint SHOULD NOT continue sending ACK frames immediately unless more
ack-eliciting packets are received out of order. If every subsequent
ack-eliciting packet arrives out of order, then an ACK frame SHOULD be sent
immediately for every received ack-eliciting packet.

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