From 4e6aec4c4bed67127b23b8b123e5cfe4e4eb24a1 Mon Sep 17 00:00:00 2001 From: ianswett Date: Wed, 11 Jul 2018 22:13:59 -0400 Subject: [PATCH 1/8] Editorial fixes --- draft-ietf-quic-recovery.md | 37 +++++++++++++++++++------------------ 1 file changed, 19 insertions(+), 18 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 42f71a6dbb..1569d641b7 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -140,9 +140,8 @@ TCP conflates transmission sequence number at the sender with delivery sequence number at the receiver, which results in retransmissions of the same data carrying the same sequence number, and consequently to problems caused by "retransmission ambiguity". QUIC separates the two: QUIC uses a packet number -for transmissions, and any data that is to be delivered to the receiving -application(s) is sent in one or more streams, with delivery order determined by -stream offsets encoded within STREAM frames. +for transmissions, and any application data is sent in one or more streams, +with delivery order determined by stream offsets encoded within STREAM frames. QUIC's packet number is strictly increasing, and directly encodes transmission order. A higher QUIC packet number signifies that the packet was sent later, @@ -216,9 +215,9 @@ implemented in QUIC. An unacknowledged packet is marked as lost when an acknowledgment is received for a packet that was sent a threshold number of packets (kReorderingThreshold) -after the unacknowledged packet. Receipt of the ack indicates that a later -packet was received, while kReorderingThreshold provides some tolerance for -reordering of packets in the network. +and/or a threshold amount of time after the unacknowledged packet. Receipt of the +ack indicates that a later packet was received, the reordering threshold +provides some tolerance for reordering of packets in the network. The RECOMMENDED initial value for kReorderingThreshold is 3. @@ -227,12 +226,13 @@ We derive this recommendation from TCP loss recovery {{?RFC5681}} reordering, causing a sender to detect spurious losses. Detecting spurious losses leads to unnecessary retransmissions and may result in degraded performance due to the actions of the congestion controller upon detecting -loss. Implementers MAY use algorithms developed for TCP, such as TCP-NCR -{{?RFC4653}}, to improve QUIC's reordering resilience, though care should be -taken to map TCP specifics to QUIC correctly. Similarly, using time-based loss -detection to deal with reordering, such as in PR-TCP, should be more readily -usable in QUIC. Making QUIC deal with such networks is important open research, -and implementers are encouraged to explore this space. +loss and spurious retransmissions. Implementers MAY use algorithms developed +for TCP, such as TCP-NCR {{?RFC4653}}, to improve QUIC's reordering resilience, +though care should be taken to map TCP specifics to QUIC correctly. + +QUIC implementations may use time-based loss detection to deal with reordering, +such as in PR-TCP. Making QUIC deal with such networks is important open +research, and implementers are encouraged to explore this space. ### Early Retransmit @@ -249,7 +249,7 @@ retransmittable packets are not acknowledged during this time, then these packets MUST be marked as lost. An endpoint SHOULD set the alarm such that a packet is marked as lost no earlier -than 1.25 * max(SRTT, latest_RTT) since when it was sent. +than 1.125 * max(SRTT, latest_RTT) since when it was sent. Using max(SRTT, latest_RTT) protects from the two following cases: @@ -260,7 +260,7 @@ Using max(SRTT, latest_RTT) protects from the two following cases: * the latest RTT sample is higher than the SRTT, perhaps due to a sustained increase in the actual RTT, but the smoothed SRTT has not yet caught up. -The 1.25 multiplier increases reordering resilience. Implementers MAY experiment +The 1.125 multiplier increases reordering resilience. Implementers MAY experiment with using other multipliers, bearing in mind that a lower multiplier reduces reordering resilience and increases spurious retransmissions, and a higher multipler increases loss recovery delay. @@ -273,8 +273,9 @@ alarm for TCP as well, and this document incorporates this advancement. ## Timer-based Detection -Timer-based loss detection implements a handshake retransmission timer that is -optimized for QUIC as well as the spirit of TCP's Tail Loss Probe and +Timer-based loss detection recovers from losses that cannot be handled by +ack-based loss detection. It uses a single timer which switches between +a handshake retransmission timer, a Tail Loss Probe timer and Retransmission Timeout mechanisms. ### Crypto Handshake Timeout @@ -628,7 +629,7 @@ are as follows: this packet, but it is not retransmittable. * is_handshake_packet: A boolean that indicates whether a packet contains - handshake data. + a CRYPTO frame in a long header packet. * sent_bytes: The number of bytes sent in the packet, not including UDP or IP overhead, but including QUIC framing overhead. @@ -653,7 +654,7 @@ Pseudocode for OnPacketSent follows: ### On Receiving an Acknowledgment -When an ACK frame is received, it may acknowledge 0 or more packets. +When an ACK frame is received, it may acknowledge 0 or more new packets. Pseudocode for OnAckReceived and UpdateRtt follow: From eec0d2f342d891289f96db5d31483837c8e9651f Mon Sep 17 00:00:00 2001 From: ianswett Date: Wed, 11 Jul 2018 22:43:01 -0400 Subject: [PATCH 2/8] Fixes --- draft-ietf-quic-recovery.md | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 1569d641b7..e7d20e9878 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -219,20 +219,18 @@ and/or a threshold amount of time after the unacknowledged packet. Receipt of th ack indicates that a later packet was received, the reordering threshold provides some tolerance for reordering of packets in the network. -The RECOMMENDED initial value for kReorderingThreshold is 3. - -We derive this recommendation from TCP loss recovery {{?RFC5681}} -{{?RFC6675}}. It is possible for networks to exhibit higher degrees of -reordering, causing a sender to detect spurious losses. Detecting spurious -losses leads to unnecessary retransmissions and may result in degraded +The RECOMMENDED initial value for kReorderingThreshold is 3, based on +TCP loss recovery {{?RFC5681}} {{?RFC6675}}. Some networks may exhibit higher +degrees of reordering, causing a sender to detect spurious losses. Detecting +spurious losses leads to unnecessary retransmissions and may result in degraded performance due to the actions of the congestion controller upon detecting -loss and spurious retransmissions. Implementers MAY use algorithms developed -for TCP, such as TCP-NCR {{?RFC4653}}, to improve QUIC's reordering resilience, -though care should be taken to map TCP specifics to QUIC correctly. +loss. Implementers MAY use algorithms developed for TCP, such as +TCP-NCR {{?RFC4653}}, to improve QUIC's reordering resilience. -QUIC implementations may use time-based loss detection to deal with reordering, -such as in PR-TCP. Making QUIC deal with such networks is important open -research, and implementers are encouraged to explore this space. +QUIC implementations may use time-based loss detection to deal with reordering. +time-based loss detection allows a certain amount of reordering above +max(SRTT, latest_rtt). The RECOMMENDED reordering tolerance is +1/8 max(SRTT, latest_rtt). ### Early Retransmit @@ -654,7 +652,7 @@ Pseudocode for OnPacketSent follows: ### On Receiving an Acknowledgment -When an ACK frame is received, it may acknowledge 0 or more new packets. +When an ACK frame is received, it may newly acknowledge any number of packets. Pseudocode for OnAckReceived and UpdateRtt follow: From d3aa88aadb1cae4fa0bd3acd009bd560362e52dd Mon Sep 17 00:00:00 2001 From: ianswett Date: Sat, 14 Jul 2018 11:06:24 -0400 Subject: [PATCH 3/8] 1.125 --- draft-ietf-quic-recovery.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index e7d20e9878..fce876f820 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -247,7 +247,7 @@ retransmittable packets are not acknowledged during this time, then these packets MUST be marked as lost. An endpoint SHOULD set the alarm such that a packet is marked as lost no earlier -than 1.125 * max(SRTT, latest_RTT) since when it was sent. +than 1.25 * max(SRTT, latest_RTT) since when it was sent. Using max(SRTT, latest_RTT) protects from the two following cases: @@ -258,7 +258,7 @@ Using max(SRTT, latest_RTT) protects from the two following cases: * the latest RTT sample is higher than the SRTT, perhaps due to a sustained increase in the actual RTT, but the smoothed SRTT has not yet caught up. -The 1.125 multiplier increases reordering resilience. Implementers MAY experiment +The 1.25 multiplier increases reordering resilience. Implementers MAY experiment with using other multipliers, bearing in mind that a lower multiplier reduces reordering resilience and increases spurious retransmissions, and a higher multipler increases loss recovery delay. From ccbbde30ea2ca4c3619f3f8f8728565d9acbb67f Mon Sep 17 00:00:00 2001 From: ianswett Date: Sat, 14 Jul 2018 15:39:49 -0400 Subject: [PATCH 4/8] Update draft-ietf-quic-recovery.md --- draft-ietf-quic-recovery.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index fce876f820..0dd46a3dd5 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -216,15 +216,15 @@ implemented in QUIC. An unacknowledged packet is marked as lost when an acknowledgment is received for a packet that was sent a threshold number of packets (kReorderingThreshold) and/or a threshold amount of time after the unacknowledged packet. Receipt of the -ack indicates that a later packet was received, the reordering threshold +ack indicates that a later packet was received, while the reordering threshold provides some tolerance for reordering of packets in the network. The RECOMMENDED initial value for kReorderingThreshold is 3, based on TCP loss recovery {{?RFC5681}} {{?RFC6675}}. Some networks may exhibit higher -degrees of reordering, causing a sender to detect spurious losses. Detecting -spurious losses leads to unnecessary retransmissions and may result in degraded -performance due to the actions of the congestion controller upon detecting -loss. Implementers MAY use algorithms developed for TCP, such as +degrees of reordering, causing a sender to detect spurious losses. Spuriously +declaring packets lost leads to unnecessary retransmissions and may result in +degraded performance due to the actions of the congestion controller upon +detecting loss. Implementers MAY use algorithms developed for TCP, such as TCP-NCR {{?RFC4653}}, to improve QUIC's reordering resilience. QUIC implementations may use time-based loss detection to deal with reordering. @@ -626,8 +626,10 @@ are as follows: ACK frame. If true, it is still expected an ack will be received for this packet, but it is not retransmittable. -* is_handshake_packet: A boolean that indicates whether a packet contains - a CRYPTO frame in a long header packet. +* is_handshake_packet: A boolean that indicates whether the packet contains + cryptographic handshake messages critical to the completion of the QUIC + handshake. In this version of QUIC, this includes any packet with the long + header that includes a CRYPTO frame. * sent_bytes: The number of bytes sent in the packet, not including UDP or IP overhead, but including QUIC framing overhead. From 6418fb72a4ea035bd1570b310ee0b4881bf618de Mon Sep 17 00:00:00 2001 From: ianswett Date: Sat, 14 Jul 2018 15:43:05 -0400 Subject: [PATCH 5/8] Update draft-ietf-quic-recovery.md --- draft-ietf-quic-recovery.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 0dd46a3dd5..0df88d6d32 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -219,7 +219,7 @@ and/or a threshold amount of time after the unacknowledged packet. Receipt of th ack indicates that a later packet was received, while the reordering threshold provides some tolerance for reordering of packets in the network. -The RECOMMENDED initial value for kReorderingThreshold is 3, based on +The RECOMMENDED initial value for kReorderingThreshold is 3, based on TCP loss recovery {{?RFC5681}} {{?RFC6675}}. Some networks may exhibit higher degrees of reordering, causing a sender to detect spurious losses. Spuriously declaring packets lost leads to unnecessary retransmissions and may result in From 8fade2b55f7efb62b158f1fa9a75b5ff22b2fdca Mon Sep 17 00:00:00 2001 From: ianswett Date: Sat, 14 Jul 2018 15:46:15 -0400 Subject: [PATCH 6/8] Update draft-ietf-quic-recovery.md --- draft-ietf-quic-recovery.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 0df88d6d32..41bd6d76db 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -215,9 +215,10 @@ implemented in QUIC. An unacknowledged packet is marked as lost when an acknowledgment is received for a packet that was sent a threshold number of packets (kReorderingThreshold) -and/or a threshold amount of time after the unacknowledged packet. Receipt of the -ack indicates that a later packet was received, while the reordering threshold -provides some tolerance for reordering of packets in the network. +and/or a threshold amount of time after the unacknowledged packet. Receipt of +the acknowledgement indicates that a later packet was received, while the +reordering threshold provides some tolerance for reordering of packets in the +network. The RECOMMENDED initial value for kReorderingThreshold is 3, based on TCP loss recovery {{?RFC5681}} {{?RFC6675}}. Some networks may exhibit higher From dcba32d0efbc2135a448880c5fbe54ffc9c657f6 Mon Sep 17 00:00:00 2001 From: ianswett Date: Sat, 14 Jul 2018 18:18:53 -0400 Subject: [PATCH 7/8] Update draft-ietf-quic-recovery.md --- draft-ietf-quic-recovery.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 41bd6d76db..61592e3f58 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -228,10 +228,10 @@ degraded performance due to the actions of the congestion controller upon detecting loss. Implementers MAY use algorithms developed for TCP, such as TCP-NCR {{?RFC4653}}, to improve QUIC's reordering resilience. -QUIC implementations may use time-based loss detection to deal with reordering. -time-based loss detection allows a certain amount of reordering above -max(SRTT, latest_rtt). The RECOMMENDED reordering tolerance is -1/8 max(SRTT, latest_rtt). +QUIC implementations can use time-based loss detection to handle reordering +based on time elapsed since the packet was sent, instead of a packet reordering +threshold. The RECOMMENDED time threshold, expressed as a fraction of the +round-trip time (kTimeReorderingFraction), is 1/8. ### Early Retransmit From 54325072f5bf5fa000cb01785dd170a6ca6a61d6 Mon Sep 17 00:00:00 2001 From: ianswett Date: Sun, 15 Jul 2018 13:39:44 -0400 Subject: [PATCH 8/8] Update draft-ietf-quic-recovery.md --- draft-ietf-quic-recovery.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 61592e3f58..55bf8d3199 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -229,8 +229,9 @@ detecting loss. Implementers MAY use algorithms developed for TCP, such as TCP-NCR {{?RFC4653}}, to improve QUIC's reordering resilience. QUIC implementations can use time-based loss detection to handle reordering -based on time elapsed since the packet was sent, instead of a packet reordering -threshold. The RECOMMENDED time threshold, expressed as a fraction of the +based on time elapsed since the packet was sent. This may be used either as +a replacement for a packet reordering threshold or in addition to it. +The RECOMMENDED time threshold, expressed as a fraction of the round-trip time (kTimeReorderingFraction), is 1/8. ### Early Retransmit