From 6b363007d1875ffb02cf6f0c9006696c72a2cd0b Mon Sep 17 00:00:00 2001 From: ianswett Date: Tue, 19 Jun 2018 08:55:01 -0400 Subject: [PATCH] Mike's comments --- draft-ietf-quic-recovery.md | 46 ++++++++++++++----------------------- 1 file changed, 17 insertions(+), 29 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index a4ec23cf24..69a06a3923 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -145,17 +145,15 @@ 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. -QUIC's packet number is strictly increasing within a packet number -space, and directly encodes transmission order. A higher QUIC packet -number signifies that the packet was sent later, and a lower QUIC -packet number signifies that the packet was sent earlier. When a -packet containing frames is deemed lost, QUIC rebundles the -retransmittable data in a new packet with a new packet number, -removing ambiguity about which packet is acknowledged when an ACK is -received. Consequently, more accurate RTT measurements can be made, -spurious retransmissions are trivially detected, and mechanisms such -as Fast Retransmit can be applied universally, based only on packet -number. +QUIC's packet number is strictly increasing, and directly encodes transmission +order. A higher QUIC packet number signifies that the packet was sent later, +and a lower QUIC packet number signifies that the packet was sent earlier. When +a packet containing frames is deemed lost, QUIC rebundles necessary frames in a +new packet with a new packet number, removing ambiguity about which packet is +acknowledged when an ACK is received. Consequently, more accurate RTT +measurements can be made, spurious retransmissions are trivially detected, and +mechanisms such as Fast Retransmit can be applied universally, based only on +packet number. This design point significantly simplifies loss detection mechanisms for QUIC. Most TCP mechanisms implicitly attempt to infer transmission ordering based on @@ -419,24 +417,6 @@ A packet sent on an RTO alarm MUST NOT be blocked by the sender's congestion controller. A sender MUST however count these bytes as additional bytes in flight, since this packet adds network load without establishing packet loss. -## Multiple Packet Number Space Optimizations {#optimizations} - -There are cases where one may be able to gain recovery information from -acknowledgements of packets in another packet number space, but they rely -on complex assumptions about the peer’s processing and acknowledgement -algorithms. Even those are unable to quickly recover from cases such as -losing the client's Initial, but receiving the 0-RTT packets. Below is -an optimization using coalesced packets and implicit acknowledgements. - - -### Crypto Handshake Data - -In order to quickly complete the handshake and avoid spurious -retransmissions due to handshake alarm timeouts, acknowledging packets -containing CRYPTO_HS frames should use a very short ack delay, such as 1ms. -ACK frames may be sent immediately when the crypto stack indicates all -data for that encryption level has been received. - ## Generating Acknowledgements QUIC SHOULD delay sending acknowledgements in response to packets, @@ -461,6 +441,14 @@ sending any ACK frames in response. In this case they can determine whether an immediate or delayed acknowledgement should be generated after processing incoming packets. +### Crypto Handshake Data + +In order to quickly complete the handshake and avoid spurious +retransmissions due to handshake alarm timeouts, handshake packets +should use a very short ack delay, such as 1ms. ACK frames may be +sent immediately when the crypto stack indicates all data for that +encryption level has been received. + ### ACK Ranges When an ACK frame is sent, one or more ranges of acknowledged packets are