← All labsTransport & networking

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
Seed42

Replay

0 ms

Wire conditions

3%
120 ms

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