QUIC loss recovery uses acknowledgments to detect lost transmissions and resend needed information, while congestion control adjusts a sending limit shared by streams in one connection.

Conceptual diagram showing packet loss in one QUIC stream while data continues on other streams in the same connection.

1. QUIC packet numbers and retransmitted information

QUIC does not assign one packet number space to every encryption level. RFC 9002 §4.1 specifies that 0-RTT and every generation of 1-RTT packets share the Application Data packet number space; packet numbers do not repeat within a space. They identify transmissions and help track their order. If information from a lost packet must be sent again, the sender places the needed frames in a new packet with a new number rather than duplicating the original packet. ACK ranges report received packet numbers. A sender can use the send time of a newly acknowledged packet, subject to acknowledgment-delay rules, to form an RTT sample. An ACK alone does not reveal path delay perfectly, so delay, reordering, and measurement conditions matter.

2. Declaring loss and firing a PTO are different events

RFC 9002 describes packet-threshold and time-threshold tests for declaring a packet lost from acknowledgment evidence. Its recommended packet threshold is three. The time threshold is based on 9/8 of the larger of the latest and smoothed RTT estimates. These tests allow some reordering while identifying packets that are sufficiently behind acknowledged traffic.

A Probe Timeout (PTO) addresses a different situation. If acknowledgment-eliciting packets remain in flight and no useful acknowledgment arrives, the sender calculates a PTO using its RTT estimate and variation, plus the peer's maximum acknowledgment delay where that term applies. When the timer expires, the sender transmits one or two acknowledgment-eliciting probe packets to prompt a response. PTO expiration alone does not declare every unacknowledged packet lost, and it does not automatically reduce the congestion window to one MSS. Acknowledgments and loss-threshold processing determine whether particular packets are later declared lost. Keeping these events distinct prevents a timeout from being treated as synonymous with retransmission or connection failure.

3. Congestion control sets a sending limit

Loss recovery and congestion control interact, but they answer different questions. Recovery tracks which transmissions have been acknowledged or declared lost and which information may need to be sent again. Congestion control limits the amount of data in flight as the sender responds to signals from the path. RFC 9002's appendix provides example pseudocode with slow start, congestion avoidance, and a recovery period. In that example, a new congestion event reduces the congestion window; acknowledged data can grow it again when the sender is not limited by the application, flow control, or recovery state. The appendix is an example algorithm, not a requirement that every QUIC implementation use exactly the same controller. Behavior depends on the implementation, its configuration, and the acknowledgments and loss signals it observes.

In RFC 9002 Appendix B’s example controller, a newly detected loss or ECN congestion event starts a recovery period and reduces the congestion window; persistent congestion can reduce it to the minimum window. The example does not grow the window for every acknowledgment: it suppresses growth when the sender is application- or flow-control-limited, or when the acknowledged packet belongs to the recovery period. These are behaviors of the RFC’s example controller, not a promise that every browser or server uses identical values.

4. Expert perspective: where packet loss can block HTTP data

HTTP/2 multiplexes several HTTP streams over one TCP connection. TCP delivers an ordered byte stream, so when bytes are missing, later bytes on that connection may wait until the gap is recovered. This transport-level head-of-line blocking can hold back data belonging to other HTTP/2 streams that share the connection.

HTTP/3 uses QUIC streams with separate offsets and ordered delivery per stream. If data is missing from one stream, later data on that same stream can wait for recovery, while data on another stream need not wait for the same missing bytes merely to preserve a single connection-wide byte order. Cloudflare's article, “The Road to QUIC,” describes this distinction and explicitly notes that congestion state is shared across QUIC streams; it says loss affecting one stream does not affect others “in most cases.” That qualification matters. Shared congestion control and connection-level flow control can still influence multiple streams, so loss is not completely isolated and HTTP/3 does not guarantee that every page will load faster.

Sources