How QUIC decides how fast to send
Every network connection shares physical links with other traffic. Send too fast, and packets queue up and get dropped. Send too slow, and you waste capacity that was available. Deciding the right rate, moment to moment, is called congestion control, and RFC 9002 defines how a QUIC sender does it — while explicitly leaving the door open for a different algorithm entirely (more on that at the end of this section).Starting cautiously: slow start
A brand-new connection has no idea what the network can handle. RFC 9002 §7.2 says a sender should start with an initial congestion window of ten times its packet size — in practice, roughly 12 KB, clamped between about 2.9 KB and 14.7 KB depending on packet size — and grow it with every packet acknowledged, doubling roughly every round trip. This is called slow start, and despite the name, it is actually an aggressive, exponential ramp-up: RFC 9002 §7.3.1 has the sender add the full size of each acknowledged packet straight onto its sending allowance.The first loss: congestion avoidance
The example controller exits slow start when it responds to a qualifying congestion event. Loss detection and recovery state determine whether a lost packet triggers that response. RFC 9002 §7.3.2 has the sender cut its sending allowance in half at that point, and switch to a much more cautious growth mode from there. This is the same “back off hard, recover slowly” shape TCP has used for decades — QUIC’s default algorithm is a close cousin of TCP’s NewReno.When it gets worse: persistent congestion
A single lost packet is normal and expected — networks lose packets. But if loss keeps happening for a long enough stretch (RFC 9002 §7.6 defines this precisely, based on the connection’s own measured round-trip time), the sender assumes something is seriously wrong with the path and drops all the way down to its minimum window, effectively starting over as if the connection were brand new.Probing for a stuck connection
If a sender goes too long without hearing anything back at all — not even a loss, just silence — it sends a small probe packet after a probe timeout (PTO), calculated from the connection’s smoothed round-trip time and its recent variation (RFC 9002 §6.2.1). Each additional silence doubles the wait before the next probe, so a sender does not hammer a genuinely dead path.This is a default, not a mandate
Here is the detail worth remembering more than any formula above: RFC 9002 explicitly does not require every QUIC connection to use this exact algorithm. Section 7 says plainly that a sender can use a different congestion controller — CUBIC is named directly as an example — as long as it plays fair with the rest of the internet’s traffic. This is why you will see different QUIC libraries (and different relays inside the same company) genuinely behave differently under load, on purpose, without breaking compatibility with each other. The wire format is shared; the sending-rate decision is not. This matters more than it might sound like it does for anything built on Media over QUIC, which is the subject of the next section — because the IETF group defining MoQ has already written down real caveats about which congestion behavior suits live media, and it is not simply “pick the newest algorithm”:- Bufferbloat. The traditional TCP-style algorithms above are prone to building up a large backlog of queued packets on a congested link — often doubling the round-trip time — before anything actually gets dropped. For a video call, a backlog like that shows up as rising, spongy latency long before you’d notice any lost frames.
- Application-limited sending. A congestion controller can only learn how much bandwidth is available by actually using it. Real-time media is often sent at a fairly fixed bitrate, well under the link’s true capacity — which means the sender may never generate enough traffic to discover how much room it actually has, and can end up underestimating the network for the entire life of the connection.
- Throughput algorithms optimize for throughput, not smoothness. Some modern algorithms (BBR is the commonly cited example) periodically cut their sending rate hard for over a round trip, specifically to remeasure the network’s true minimum latency. That’s a reasonable trade for a file download. For a live call, it can look like a short, repeating stutter.
Check your understanding
A media source generates 2 Mbps while the network could carry 20 Mbps. Does its observed delivery rate establish that the path capacity is only 2 Mbps?Worked answer
Worked answer
No. The source is application-limited: it has no additional data to send.
The observed delivery rate measures this workload, not the maximum path capacity.
Flow control and congestion control are additional constraints and need separate evidence.