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

Out of order relative to other ack-eliciting packets #4000

Merged
merged 9 commits into from
Sep 1, 2020
Merged

Out of order relative to other ack-eliciting packets #4000

Changes from all commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
e0e024d
Out of order relative to other ack-eliciting packets
ianswett Aug 16, 2020
3ca0b89
Update draft-ietf-quic-transport.md
ianswett Aug 17, 2020
5cdb166
Martin's suggestion
ianswett Aug 17, 2020
ea6359f
Update draft-ietf-quic-transport.md
ianswett Aug 17, 2020
b89274c
Line break to enable bullets
MikeBishop Aug 17, 2020
a881299
Update draft-ietf-quic-transport.md
ianswett Aug 18, 2020
d7a4c50
Update draft-ietf-quic-transport.md
ianswett Aug 18, 2020
c467dba
Remove out-of-order definition
ianswett Aug 18, 2020
b7b431b
Remove redundant SHOULD NOT
ianswett Aug 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
22 changes: 9 additions & 13 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -222,13 +222,6 @@ Ack-eliciting Packet:
CONNECTION_CLOSE. These cause a recipient to send an acknowledgment; see
{{sending-acknowledgements}}.

Out-of-order packet:

: A packet that does not increase the largest received packet number for its
packet number space ({{packet-numbers}}) by exactly one. A packet can arrive
out of order if it is delayed, if earlier packets are lost or delayed, or if
the sender intentionally skips a packet number.

Endpoint:

: An entity that can participate in a QUIC connection by generating, receiving,
Expand Down Expand Up @@ -3557,12 +3550,15 @@ which could prevent the connection from ever becoming idle. Non-ack-eliciting
packets are eventually acknowledged when the endpoint sends an ACK frame in
response to other events.

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
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.
In order to assist loss detection at the sender, an endpoint SHOULD generate
and send an ACK frame without delay when it receives an ack-eliciting packet
either:

* when the received packet has a packet number less than another ack-eliciting
packet that has been received, or
* when the packet has a packet number larger than the highest-numbered
ack-eliciting packet that has been received and there are missing packets
Copy link
Member

Choose a reason for hiding this comment

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

This wording strikes me as odd. A receiver does not know whether there are missing packets. We should simply state that there is a gap in the packet numbers.

Copy link
Contributor

Choose a reason for hiding this comment

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

@dtikhonov : Missing packets is not the same as lost packets. The receiver knows when packets are missing, it just doesn't know whether they are reordered or lost.

between that packet and this 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