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

Remove 1 RTT delayed ack requirement #3055

Merged
merged 4 commits into from
Oct 15, 2019
Merged

Remove 1 RTT delayed ack requirement #3055

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
cdad59a
Remove 1 RTT delayed ack requirement
ianswett Sep 20, 2019
3696d8c
Update draft-ietf-quic-transport.md
ianswett Sep 20, 2019
ace2a50
Remove obsolete text on ACKing CRYPTO frames
ianswett Sep 20, 2019
114d984
Update draft-ietf-quic-transport.md
ianswett Sep 24, 2019
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
30 changes: 10 additions & 20 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3009,11 +3009,16 @@ guidance offered below seeks to strike this balance.
An ACK frame SHOULD be generated for at least every second ack-eliciting packet.
This recommendation is in keeping with standard practice for TCP {{?RFC5681}}.

A receiver's delayed acknowledgment timer SHOULD NOT exceed the current RTT
estimate or the value it indicates in the `max_ack_delay` transport parameter.
This ensures an acknowledgment is sent at least once per RTT when packets
needing acknowledgement are received. The sender can use the receiver's
`max_ack_delay` value in determining timeouts for timer-based retransmission.
An endpoint MUST NOT excessively delay acknowledgements of ack-eliciting
packets. An endpoint commits to a maximum delay using the max_ack_delay
transport parameter; see {{transport-parameter-definitions}}. max_ack_delay
declares an explicit contract: an endpoint promises to never delay
acknowledgments of an ack-eliciting packet by more than the indicated value. If
it does, any excess accrues to the RTT estimate and could result in delayed
retransmissions from the peer. For Initial and Handshake packets, a
max_ack_delay of 0 is used. The sender uses the receiver's `max_ack_delay`
value in determining timeouts for timer-based retransmission, as detailed
in Section 5.2.1 of {{QUIC-RECOVERY}}.

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
Expand All @@ -3033,12 +3038,6 @@ ACK frames in response. In this case the receiver can determine whether an
immediate or delayed acknowledgement should be generated after processing
incoming packets.

Acknowledgements of packets carrying CRYPTO frames SHOULD be minimally delayed,
to complete the handshake with minimal latency. Delaying them by a small amount,
such as the local timer granularity, allows the endpoint to bundle any data sent
in response with the ACK frame. ACK frames SHOULD be sent immediately when the
crypto stack indicates all data for that packet number space has been received.

Packets containing PADDING frames are considered to be in flight for congestion
control purposes {{QUIC-RECOVERY}}. Sending only PADDING frames might cause the
sender to become limited by the congestion controller (as described in
Expand Down Expand Up @@ -3137,15 +3136,6 @@ be held in the OS kernel or elsewhere on the host before being processed. An
endpoint MUST NOT include delays that is does not control when populating the
Ack Delay field in an ACK frame.

An endpoint MUST NOT excessively delay acknowledgements of ack-eliciting
packets. An endpoint commits to a maximum delay using the max_ack_delay
transport parameter; see {{transport-parameter-definitions}}. max_ack_delay
declares an explicit contract: an endpoint promises to never delay
acknowledgments of an ack-eliciting packet by more than the indicated value. If
it does, any excess accrues to the RTT estimate and could result in delayed
retransmissions from the peer. For Initial and Handshake packets, a
max_ack_delay of 0 is used.

### ACK Frames and Packet Protection

ACK frames MUST only be carried in a packet that has the same packet
Expand Down