Transport & networking
Head of Line
Run the same lossy wire through TCP and QUIC — watch one stall and the other route around it.
How to read this lab
The exact same lossy connection carries 4 streams under two transports at once. Under TCP, a single lost packet freezes ALL 4 streams until it's retransmitted. Under QUIC, only the stream that lost a packet stalls — but all 4 still slow down a little, because they share one congestion window.
Controls
- Loss probability
- How likely any given packet is to be dropped on the wire — both transports see the identical loss pattern for a fair comparison.
- RTT
- Round-trip time, which sets how long a lost packet takes to be detected and retransmitted.
- Auto-play
- Replays the scenario forward automatically; scrubbing manually pauses it.
- Scrub
- Drag to any point in the replay and watch both transports' state at that instant.
- Pause / Play, Restart
- Standard playback controls for the replay.
What to watch for
- Watch a loss hit stream A — in the TCP pane, ALL 4 lanes freeze and then burst forward together once the retransmit lands.
- In the QUIC pane at the same moment, only stream A's lane stalls; B, C, D keep delivering — just a little slower than before.
- Shared cwnd drops right when the loss happens, and QUIC advantage shows how much time QUIC saved the unaffected streams over TCP for this exact run.
Why it happens
TCP delivers one ordered byte-stream — if a packet is lost, everything sequenced after it is stuck behind it in that one queue, regardless of which logical stream it belongs to, until the gap is filled. QUIC gives each stream its own independent delivery order, so a loss on stream A only blocks stream A's own later data. But both protocols still share ONE congestion window for the whole connection — any loss anywhere forces that window, and therefore everyone's send rate, to shrink. QUIC fixes head-of-line blocking (ordering); it does not make you immune to a shared network event.
Try this first — Set Loss probability high (around 10%) and RTT high (around 250ms), then compare the TCP and QUIC slowest-stream times.
No loss yet — both models agree
No loss has happened yet at 0ms into the replay — TCP and QUIC are delivering all 4 streams on the identical schedule. Watch for the red dashed line: that's where they'll diverge.
- Stream A (lossy)
- Stream B
- Stream C
- Stream D
- Loss event
Replay
Wire conditions
Both models are fed the exact same seeded loss pattern and RTT, so the comparison is fair: TCP's one ordered byte-stream stalls every lane after any loss; QUIC keeps unrelated streams flowing, but all streams still share one congestion window, so pacing slows for everyone after a loss.
Shared cwnd
16.0
of 16 initial
TCP slowest stream
3066 ms
Completion time (all lanes share one stall)
QUIC slowest stream
3028 ms
Completion time (only the lossy stream stalls)
QUIC advantage
38 ms
Time saved vs. TCP for this run
Stream A
2943 ms / 2823 ms
TCP / QUIC completion
Stream B
2986 ms / 2866 ms
TCP / QUIC completion
Stream C
3028 ms / 3028 ms
TCP / QUIC completion
Stream D
3066 ms / 2946 ms
TCP / QUIC completion