From 9cf53b9ced77e3434f8ff5d47a0ff4795c148ca2 Mon Sep 17 00:00:00 2001 From: ianswett Date: Mon, 3 Aug 2020 10:03:55 -0400 Subject: [PATCH 1/3] Make the ack-tracking examplary It's no longer normative and it's in a single section. --- draft-ietf-quic-transport.md | 50 +++++++++++++++++------------------- 1 file changed, 23 insertions(+), 27 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index c22be5702e..3b76f38cc2 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3571,6 +3571,9 @@ non-ack-eliciting packets need to be acknowledged, an endpoint MAY wait until an ack-eliciting packet has been received to include an ACK frame with outgoing frames. +A receiver MUST NOT send an ack-eliciting frame in all packets that would +otherwise be non-ack-eliciting, to avoid an infinite feedback loop of +acknowledgements. ### Acknowledgement Frequency @@ -3614,29 +3617,6 @@ spuriously retransmitting the frames it contains. An ACK frame is expected to fit within a single QUIC packet. If it does not, then older ranges (those with the smallest packet numbers) are omitted. -{{ack-tracking}} and {{ack-limiting}} describe an exemplary approach for -determining what packets to acknowledge in each ACK frame. Though the goal of -these algorithms is to generate an acknowledgment for every packet that is -processed, it is still possible for acknowledgments to be lost. A sender cannot -expect to receive an acknowledgment for every packet that the receiver -processes. - - -### Receiver Tracking of ACK Frames {#ack-tracking} - -When a packet containing an ACK frame is sent, the largest acknowledged in that -frame may be saved. When a packet containing an ACK frame is acknowledged, the -receiver can stop acknowledging packets less than or equal to the largest -acknowledged in the sent ACK frame. - -In cases without ACK frame loss, this algorithm allows for a minimum of 1 RTT of -reordering. In cases with ACK frame loss and reordering, this approach does not -guarantee that every acknowledgement is seen by the sender before it is no -longer included in the ACK frame. Packets could be received out of order and all -subsequent ACK frames containing them could be lost. In this case, the loss -recovery algorithm could cause spurious retransmissions, but the sender will -continue making forward progress. - ### Limiting ACK Ranges {#ack-limiting} A receiver limits the number of ACK Ranges ({{ack-ranges}}) it remembers and @@ -3666,6 +3646,19 @@ validation at a sender and including a lower value than what was included in a previous ACK frame could cause ECN to be unnecessarily disabled; see {{ecn-validation}}. +{{ack-tracking}} describes an exemplary approach for determining what packets +to acknowledge in each ACK frame. Though the goal of this algorithm is to +generate an acknowledgment for every packet that is processed, it is still +possible for acknowledgments to be lost. A sender cannot expect to receive +an acknowledgment for every packet that the receiver processes. + +### Limiting Ranges by Tracking ACK Frames {#ack-tracking} + +When a packet containing an ACK frame is sent, the largest acknowledged in that +frame may be saved. When a packet containing an ACK frame is acknowledged, the +receiver can stop acknowledging packets less than or equal to the largest +acknowledged in the sent ACK frame. + A receiver that sends only non-ack-eliciting packets, such as ACK frames, might not receive an acknowledgement for a long period of time. This could cause the receiver to maintain state for a large number of ACK frames for a long period of @@ -3673,10 +3666,13 @@ time, and ACK frames it sends could be unnecessarily large. In such a case, a receiver could send a PING or other small ack-eliciting frame occasionally, such as once per round trip, to elicit an ACK from the peer. -A receiver MUST NOT send an ack-eliciting frame in all packets that would -otherwise be non-ack-eliciting, to avoid an infinite feedback loop of -acknowledgements. - +In cases without ACK frame loss, this algorithm allows for a minimum of 1 RTT of +reordering. In cases with ACK frame loss and reordering, this approach does not +guarantee that every acknowledgement is seen by the sender before it is no +longer included in the ACK frame. Packets could be received out of order and all +subsequent ACK frames containing them could be lost. In this case, the loss +recovery algorithm could cause spurious retransmissions, but the sender will +continue making forward progress. ### Measuring and Reporting Host Delay {#host-delay} From 9663dc9ab37d0ec82b45d542e461573ff06f0cbe Mon Sep 17 00:00:00 2001 From: ianswett Date: Mon, 3 Aug 2020 10:19:47 -0400 Subject: [PATCH 2/3] Update draft-ietf-quic-transport.md --- draft-ietf-quic-transport.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 3b76f38cc2..68a1be6b58 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3617,8 +3617,6 @@ spuriously retransmitting the frames it contains. An ACK frame is expected to fit within a single QUIC packet. If it does not, then older ranges (those with the smallest packet numbers) are omitted. -### Limiting ACK Ranges {#ack-limiting} - A receiver limits the number of ACK Ranges ({{ack-ranges}}) it remembers and sends in ACK frames, both to limit the size of ACK frames and to avoid resource exhaustion. After receiving acknowledgments for an ACK frame, the receiver From f6ffebe16738c836b4bcaf174e2ca6776ab37072 Mon Sep 17 00:00:00 2001 From: ianswett Date: Mon, 10 Aug 2020 17:48:44 -0400 Subject: [PATCH 3/3] Move a sentence up and tweak Based on @MikeBishop note --- draft-ietf-quic-transport.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 68a1be6b58..5a7f0e341d 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3620,7 +3620,9 @@ to fit within a single QUIC packet. If it does not, then older ranges A receiver limits the number of ACK Ranges ({{ack-ranges}}) it remembers and sends in ACK frames, both to limit the size of ACK frames and to avoid resource exhaustion. After receiving acknowledgments for an ACK frame, the receiver -SHOULD stop tracking those acknowledged ACK Ranges. +SHOULD stop tracking those acknowledged ACK Ranges. Senders can expect +acknowledgements for most packets, but QUIC does not guarantee receipt of an +acknowledgment for every packet that the receiver processes. It is possible that retaining many ACK Ranges could cause an ACK frame to become too large. A receiver can discard unacknowledged ACK Ranges to limit ACK frame @@ -3647,8 +3649,7 @@ previous ACK frame could cause ECN to be unnecessarily disabled; see {{ack-tracking}} describes an exemplary approach for determining what packets to acknowledge in each ACK frame. Though the goal of this algorithm is to generate an acknowledgment for every packet that is processed, it is still -possible for acknowledgments to be lost. A sender cannot expect to receive -an acknowledgment for every packet that the receiver processes. +possible for acknowledgments to be lost. ### Limiting Ranges by Tracking ACK Frames {#ack-tracking}