Learning objective. Understand why the reliability that helps bulk transfer can hurt interactive traffic, and what levers QUIC gives you to tune loss recovery and congestion control for latency and jitter rather than for throughput.
Freshness beats completeness #
Everything so far optimizes for delivering all the data, eventually. Real-time traffic (a video call, cloud gaming, live telemetry) wants something different: the freshest data, now. A retransmitted video frame that arrives after its playout deadline is worse than useless; the decoder has already moved on, and the late packet only consumed bandwidth and CPU. The governing question flips from "did everything arrive?" to "did it arrive in time?"
The timeline shows the unavoidable arithmetic: even QUIC's fast, ACK-driven loss detection (§3.1) needs roughly a round trip to notice a loss, and the retransmission needs another one-way trip to arrive. On a 100 ms path that is ~150 ms of added delay: fine for a file, fatal for a 60 fps frame due in 16 ms. No transport tuning removes this; the win comes from choosing not to retransmit what will be stale, and from keeping the timers honest so you neither wait too long nor recover things you did not lose.
The levers #
Most of what follows is editorial tuning judgment, not normative requirement. But each lever rests on a mechanism from this chapter.
Choose the right reliability model. For data where a late copy is worthless, don't make
QUIC retransmit it. DATAGRAM frames (§1.4, RFC 9221) are delivered once or not
at all. They are congestion-controlled and encrypted, but not retransmitted on loss
([RFC 9221 §5]), so the application, not the transport, decides whether to resend a fresher
version. Reserve reliable STREAMs for data that must arrive (control messages, key frames)
and use datagrams for the disposable stream (inter-frame deltas, position updates). This is
developed fully in Chapter 9.
Pick a congestion controller that tolerates non-congestive loss. Wireless paths drop packets for reasons unrelated to queue buildup. A purely loss-based controller reads every drop as congestion and backs off (§3.3); a model-based one like BBR, or ECN where the path supports it, keeps the rate up when the loss is not congestion. The choice is an integration point, not a protocol change.
Keep the timers honest, not aggressive. Jitter inflates rttvar, which inflates the PTO
(§3.2) and slows tail recovery. But tightening timers to compensate invites
spurious retransmissions that waste the very bandwidth real-time traffic needs. The packet
threshold (3) and time threshold (9/8 × RTT) already tolerate reordering (§3.1);
lowering them on a reordering-prone radio link causes more harm than good. Prefer accurate
RTT sampling (steady ACKs) over shorter timers.
editorial A useful rule of thumb: if the application can tolerate a gap better than a delay, it should be on a datagram or an expendable stream, and the transport should be told (via the congestion controller and ACK-frequency choices) to favor timeliness. Watch two things in a capture: the interval between a loss and its retransmission (your recovery latency floor, ≈ RTT + jitter), and the spurious-retransmit rate (frames resent that were merely reordered). Tune to shrink the first only until the second starts rising. And remember stream independence (§4.4) helps other streams during a loss, but does nothing for the freshness of the stream that took the hit.
Takeaways #
Reliability is a cost, not a free good, for interactive traffic: detection plus retransmission is at least a round trip, and a late arrival is wasted. QUIC's answer is not a magic setting but a set of deliberate choices — unreliable datagrams for disposable data, a loss-tolerant congestion controller, and honestly-tuned timers — that trade completeness for freshness where the application prefers it. §3.5 closes the chapter by reading real loss and ACK traces to see recovery actually happen.