13. Packetization and Reliability
13. Packetization and Reliability
A sender sends one or more frames in a QUIC packet (Section 12.4). A sender can minimize per-packet bandwidth and computational costs by including as many frames as possible in each QUIC packet. A sender MAY wait for a short period of time to collect multiple frames before sending a packet that is not maximally packed, to avoid sending out large numbers of small packets.
13.1 Packet Processing
A packet MUST NOT be acknowledged until packet protection has been successfully removed and all frames contained in the packet have been processed. For STREAM frames, this means the data has been enqueued in preparation to be received by the application protocol, but it does not require that data is delivered and consumed.
13.2 Generating Acknowledgments
Endpoints acknowledge all packets they receive and process. However, only ack-eliciting packets cause an ACK frame to be sent within the maximum ack delay. Packets that are not ack-eliciting are only acknowledged when an ACK frame is sent for other reasons.
13.2.1 Sending ACK Frames
Every packet SHOULD be acknowledged at least once, and ack-eliciting packets MUST be acknowledged at least once within the maximum delay an endpoint communicated using the max_ack_delay transport parameter; see Section 18.2.
13.2.2 Acknowledgment Frequency
A receiver determines how frequently to send acknowledgments in response to ack-eliciting packets. This determination is implementation-specific.
13.2.3 Managing ACK Ranges
When an ACK frame is sent, one or more ranges of acknowledged packets are included. Including older ranges reduces the chance of spurious retransmits caused by losing previously sent ACK frames.
13.2.4 Limiting Ranges by Tracking ACK Frames
When a sender receives an acknowledgment for a packet containing an ACK frame, the sender can stop acknowledging packets less than or equal to the largest acknowledged in that ACK frame.
13.2.5 Measuring and Reporting Host Delay
An endpoint measures the delay from when an ack-eliciting packet is received to when the corresponding ACK is sent.
13.2.6 ACK Frames and Packet Protection
ACK frames MUST only be carried in a packet that has the same packet number space as the packet being acknowledged.
13.2.7 PADDING Frames Consume Congestion Window
Packets containing PADDING frames are considered to be in flight for congestion control purposes [QUIC-RECOVERY].
13.3 Retransmission of Information
QUIC uses a combination of negative acknowledgment (NACK) and positive acknowledgment (ACK) to trigger retransmission. QUIC packets are not retransmitted whole; when packets are determined to be lost, the information that might be carried in them is sent again in new packets as needed.
New frames and packets are used to carry information that is determined to have been lost. In general, information is sent again when a packet containing that information is determined to be lost and sending ceases when a packet containing that information is acknowledged.
13.4 Explicit Congestion Notification
QUIC endpoints use Explicit Congestion Notification (ECN) [RFC3168] to detect and respond to network congestion. ECN allows an endpoint to mark packets to request that a network element add a congestion experienced (CE) marking rather than drop the packet.
13.4.1 Reporting ECN Counts
Use of ECN requires that both endpoints enable ECN in IP packets and report reception of CE markings in QUIC ACK frames.
13.4.2 ECN Validation
It is possible for faulty network devices to corrupt or erroneously drop packets that carry a non-zero ECN codepoint. To ensure connectivity in the presence of such devices, an endpoint validates the ECN counts it receives from its peer and disables ECN if the counts appear unreliable.