diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 42f71a6dbb..200bd3cd6c 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -100,23 +100,25 @@ This design obviates the need for disambiguating between transmissions and retransmissions and eliminates significant complexity from QUIC's interpretation of TCP loss detection mechanisms. -Every packet may contain several frames. We outline the frames that are -important to the loss detection and congestion control machinery below. - -* Retransmittable frames are those that count towards bytes in flight and need - acknowledgement. The most common are STREAM frames, which typically contain - application data. - -* Retransmittable packets are those that contain at least one retransmittable - frame. - -* Cryptographic handshake data is sent in CRYPTO frames, and uses the - reliability machinery of QUIC underneath. - -* ACK and ACK_ECN frames contain acknowledgment information. ACK_ECN frames - additionally contain information about ECN codepoints seen by the peer. (The - rest of this document uses ACK frames to refer to both ACK and ACK_ECN - frames.) +QUIC packets can contain multiple frames of different types. The recovery +mechanisms ensure that data and frames that need reliable delivery are +acknowledged or declared lost and sent in new packets as necessary. The types +of frames contained in a packet affect recovery and congestion control logic: + +* All packets are acknowledged, though packets that contain only ACK, + ACK_ECN, and PADDING frames are not acknowledged immediately. Packets + containing at least one frame besides ACK, ACK_ECN, and PADDING are referred + to as "retransmittable" below. + +* Long header packets that contain CRYPTO frames are critical to the + performance of the QUIC handshake and use shorter timers for acknowledgement + and retransmission. + +* Packets that contain only ACK and ACK_ECN frames do not count toward + congestion control limits and are not considered in-flight. Note that this + means PADDING frames cause packets to contribute toward bytes in flight + without directly causing an acknowledgment to be sent. The rest of this + document uses "ACK frames" to refer to both ACK and ACK_ECN frames. ## Relevant Differences Between QUIC and TCP @@ -242,10 +244,10 @@ packets cannot be detected via Fast Retransmit. To enable ack-based loss detection of such packets, receipt of an acknowledgment for the last outstanding retransmittable packet triggers the Early Retransmit process, as follows. -If there are unacknowledged retransmittable packets still pending, they should +If there are unacknowledged in-flight packets still pending, they should be marked as lost. To compensate for the reduced reordering resilience, the sender SHOULD set an alarm for a small period of time. If the unacknowledged -retransmittable packets are not acknowledged during this time, then these +in-flight 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 @@ -582,7 +584,8 @@ sent_packets: : An association of packet numbers to information about them, including a number field indicating the packet number, a time field indicating the time a packet - was sent, a boolean indicating whether the packet is ack only, and a bytes + was sent, a boolean indicating whether the packet is ack only, a boolean + indicating whether it counts towards bytes in flight, and a bytes field indicating the packet's size. sent_packets is ordered by packet number, and packets remain in sent_packets until acknowledged or lost. A sent_packets data structure is maintained per packet number space, and ACK processing only @@ -623,9 +626,12 @@ are as follows: * packet_number: The packet number of the sent packet. -* is_ack_only: A boolean that indicates whether a packet only contains an - ACK frame. If true, it is still expected an ack will be received for - this packet, but it is not retransmittable. +* ack_only: A boolean that indicates whether a packet contains only + ACK or PADDING frame(s). If true, it is still expected an ack will + be received for this packet, but it is not retransmittable. + +* in_flight: A boolean that indicates whether the packet counts towards + bytes in flight. * is_handshake_packet: A boolean that indicates whether a packet contains handshake data. @@ -636,13 +642,14 @@ are as follows: Pseudocode for OnPacketSent follows: ~~~ - OnPacketSent(packet_number, is_ack_only, is_handshake_packet, - sent_bytes): + OnPacketSent(packet_number, ack_only, in_flight, + is_handshake_packet, sent_bytes): largest_sent_packet = packet_number sent_packets[packet_number].packet_number = packet_number sent_packets[packet_number].time = now - sent_packets[packet_number].ack_only = is_ack_only - if !is_ack_only: + sent_packets[packet_number].ack_only = ack_only + sent_packets[packet_number].in_flight = in_flight + if !ack_only: if is_handshake_packet: time_of_last_sent_handshake_packet = now time_of_last_sent_retransmittable_packet = now @@ -768,8 +775,8 @@ Pseudocode for SetLossDetectionAlarm follows: ~~~ SetLossDetectionAlarm(): - // Don't arm the alarm if there are no packets with - // retransmittable data in flight. + // Don't arm alarm if there are no retransmittable packets + // in flight. if (bytes_in_flight == 0): loss_detection_alarm.cancel() return @@ -966,7 +973,7 @@ slow start is re-entered. ## Pacing This document does not specify a pacer, but it is RECOMMENDED that a sender pace -sending of all retransmittable packets based on input from the congestion +sending of all in-flight packets based on input from the congestion controller. For example, a pacer might distribute the congestion window over the SRTT when used with a window-based controller, and a pacer might use the rate estimate of a rate-based controller. @@ -1018,8 +1025,9 @@ ecn_ce_counter: bytes_in_flight: : The sum of the size in bytes of all sent packets that contain at least - one retransmittable frame, and have not been acked or declared - lost. The size does not include IP or UDP overhead. + one retransmittable or PADDING frame, and have not been acked or declared + lost. The size does not include IP or UDP overhead, but does include the + QUIC header and AEAD overhead. Packets only containing ACK frames do not count towards bytes_in_flight to ensure congestion control does not impede congestion feedback.