diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 9fb5446f15..6c8d9d84f4 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -130,9 +130,11 @@ In-flight packets: All transmissions in QUIC are sent with a packet-level header, which indicates the encryption level and includes a packet sequence number (referred to below as a packet number). The encryption level indicates the packet number space, as -described in Section 12.3 of {{QUIC-TRANSPORT}}. Packet numbers never repeat -within a packet number space for the lifetime of a connection. Packet numbers +described in Section 12.3 in {{QUIC-TRANSPORT}}. Packet numbers never repeat +within a packet number space for the lifetime of a connection. Packet numbers are sent in monotonically increasing order within a space, preventing ambiguity. +It is permitted for some packet numbers to never be used, leaving intentional +gaps. This design obviates the need for disambiguating between transmissions and retransmissions; this eliminates significant complexity from QUIC's @@ -353,8 +355,8 @@ frequently observable. ## Estimating smoothed_rtt and rttvar {#smoothed-rtt} smoothed_rtt is an exponentially-weighted moving average of an endpoint's RTT -samples, and rttvar is the variation in the RTT samples, estimated using a -mean variation. +samples, and rttvar estimates the variation in the RTT samples using a mean +variation. The calculation of smoothed_rtt uses RTT samples after adjusting them for acknowledgment delays. These delays are decoded from the ACK Delay field of @@ -363,15 +365,15 @@ ACK frames as described in Section 19.3 of {{QUIC-TRANSPORT}}. The peer might report acknowledgment delays that are larger than the peer's max_ack_delay during the handshake (Section 13.2.1 of {{QUIC-TRANSPORT}}). To account for this, the endpoint SHOULD ignore max_ack_delay until the handshake -is confirmed (Section 4.1.2 of {{QUIC-TLS}}). When they occur, these large -acknowledgment delays are likely to be non-repeating and limited to the -handshake. The endpoint can therefore use them without limiting them to the +is confirmed, as defined in Section 4.1.2 of {{QUIC-TLS}}. When they occur, +these large acknowledgment delays are likely to be non-repeating and limited to +the handshake. The endpoint can therefore use them without limiting them to the max_ack_delay, avoiding unnecessary inflation of the RTT estimate. -Note however that a large acknowledgment delay can result in a substantially -inflated smoothed_rtt, if there is either an error in the peer's reporting of -the acknowledgment delay or in the endpoint's min_rtt estimate. Therefore, -prior to handshake confirmation, an endpoint MAY ignore RTT samples if adjusting +Note that a large acknowledgment delay can result in a substantially inflated +smoothed_rtt, if there is either an error in the peer's reporting of the +acknowledgment delay or in the endpoint's min_rtt estimate. Therefore, prior +to handshake confirmation, an endpoint MAY ignore RTT samples if adjusting the RTT sample for acknowledgment delay causes the sample to be less than the min_rtt. @@ -665,7 +667,7 @@ Since the server could be blocked until more datagrams are received from the client, it is the client's responsibility to send packets to unblock the server until it is certain that the server has finished its address validation (see Section 8 of {{QUIC-TRANSPORT}}). That is, the client MUST set the -probe timer if the client has not received an acknowledgment for one of its +probe timer if the client has not received an acknowledgment for any of its Handshake packets and the handshake is not confirmed (see Section 4.1.2 of {{QUIC-TLS}}), even if there are no packets in flight. When the PTO fires, the client MUST send a Handshake packet if it has Handshake keys, otherwise it @@ -700,7 +702,7 @@ its first flight. When a PTO timer expires, a sender MUST send at least one ack-eliciting packet in the packet number space as a probe. An endpoint MAY send up to two full-sized datagrams containing ack-eliciting packets, to avoid an expensive -consecutive PTO expiration due to a single lost datagram or transmit data +consecutive PTO expiration due to a single lost datagram, or transmit data from multiple packet number spaces. All probe packets sent on a PTO MUST be ack-eliciting. @@ -765,11 +767,11 @@ initial RTT estimate. ## Discarding Keys and Packet State {#discarding-packets} -When packet protection keys are discarded (see Section 4.9 of {{QUIC-TLS}}), -all packets that were sent with those keys can no longer be acknowledged because -their acknowledgments cannot be processed anymore. The sender MUST discard -all recovery state associated with those packets and MUST remove them from -the count of bytes in flight. +When Initial and Handshake packet protection keys are discarded +(see Section 4.9 of {{QUIC-TLS}}), all packets that were sent with those keys +can no longer be acknowledged because their acknowledgments cannot be processed. +The sender MUST discard all recovery state associated with those packets +and MUST remove them from the count of bytes in flight. Endpoints stop sending and receiving Initial packets once they start exchanging Handshake packets; see Section 17.2.2.1 of {{QUIC-TRANSPORT}}. At this point, @@ -783,9 +785,9 @@ before Initial packets, early 0-RTT packets will be declared lost, but that is expected to be infrequent. It is expected that keys are discarded after packets encrypted with them would -be acknowledged or declared lost. However, Initial secrets are discarded as -soon as handshake keys are proven to be available to both client and server; -see Section 4.9.1 of {{QUIC-TLS}}. +be acknowledged or declared lost. However, Initial and Handshake secrets are +discarded as soon as handshake and 1-RTT keys are proven to be available to both +client and server; see Section 4.9.1 of {{QUIC-TLS}}. # Congestion Control {#congestion-control} @@ -1017,7 +1019,9 @@ Since network congestion is not affected by packet number spaces, persistent congestion SHOULD consider packets sent across packet number spaces. A sender that does not have state for all packet number spaces or an implementation that cannot compare send times across packet number spaces MAY use state for just the -packet number space that was acknowledged. +packet number space that was acknowledged. This might result in erroneously +declaring persistent congestion, but it will not lead to a failure to detect +persistent congestion. When persistent congestion is declared, the sender's congestion window MUST be reduced to the minimum congestion window (kMinimumWindow), similar to a TCP @@ -1300,7 +1304,7 @@ largest_acked_packet\[kPacketNumberSpace]: : The largest packet number acknowledged in the packet number space so far. loss_time\[kPacketNumberSpace]: -: The time at which the next packet in that packet number space will be +: The time at which the next packet in that packet number space can be considered lost based on exceeding the reordering window in time. sent_packets\[kPacketNumberSpace]: @@ -1433,8 +1437,7 @@ UpdateRtt(ack_delay): // min_rtt ignores acknowledgment delay. min_rtt = min(min_rtt, latest_rtt) // Limit ack_delay by max_ack_delay after handshake - // confirmation. Note that ack_delay is 0 for - // acknowledgments of Initial and Handshake packets. + // confirmation. if (handshake confirmed): ack_delay = min(ack_delay, max_ack_delay) @@ -1527,7 +1530,6 @@ SetLossDetectionTimer(): loss_detection_timer.cancel() return - // Determine which PN space to arm PTO for. timeout, _ = GetPtoTimeAndSpace() loss_detection_timer.update(timeout) ~~~ @@ -1655,8 +1657,8 @@ kMinimumWindow: : Minimum congestion window in bytes as described in {{initial-cwnd}}. kLossReductionFactor: -: Reduction in congestion window when a new loss event is detected. - {{congestion-control}} recommends a value is 0.5. +: Scaling factor applied to reduce the congestion window when a new loss event + is detected. {{congestion-control}} recommends a value is 0.5. kPersistentCongestionThreshold: : Period of time for persistent congestion to be established, specified as a PTO @@ -1692,9 +1694,9 @@ congestion_window: : Maximum number of bytes allowed to be in flight. congestion_recovery_start_time: -: The time when QUIC first detects congestion due to loss or ECN, causing - it to enter congestion recovery. When a packet sent after this time is - acknowledged, QUIC exits congestion recovery. +: The time the current recovery period started due to the detection of loss + or ECN. When a packet sent after this time is acknowledged, QUIC exits + congestion recovery. ssthresh: : Slow start threshold in bytes. When the congestion window is below ssthresh,