Head of Line
See how one lost packet can hold up messages; compare TCP and QUIC.
TrySet Loss probability around 10% and Round-trip time around 250 ms, then compare the TCP and QUIC slowest-stream times.
Watch forTCP stalls all streams behind one loss. QUIC preserves other streams, but shared congestion can slow all.
Standalone teaching model; it represents no production implementation.
Interactive model
Skill practicedUnderstand how a lost packet can delay a stream of messages
Transferable practiceCompare two network transports when a packet is lost; the timing here is a simplified model, not a real-network prediction.
Understand the result
TCP and QUIC are compared under the same deterministic loss pattern across four streams. This model uses a fixed one-RTT loss-recovery delay and simplified shared congestion behavior; its timing illustrates relative blocking rather than predicting a real network.
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.
- Round-trip time (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. With reduced motion enabled, auto-play and Play are unavailable; use the scrubber or Restart.
- Scrub
- Drag to any point in the replay and watch both transports' state at that instant.
- Pause
- Appears while the replay is running; pauses automatic playback.
- Play
- Appears while the replay is paused; resumes automatic playback. It is disabled when reduced motion is enabled.
- Restart
- Moves the replay scrubber back to the start of the current packet-loss run.
- Reseed
- Generates a different deterministic packet-loss pattern and restarts the paired TCP/QUIC replay.
What to watch for
- A loss can hit any stream. In TCP, later delivery across all four lanes waits behind the missing chunk until recovery. With reduced motion, scrub through the replay manually to compare where each transport stalls.
- In QUIC, later chunks wait only on streams with an outstanding loss; other streams keep their own delivery order, while the shared congestion window can slow pacing for everyone.
- Watch Shared cwnd fall after a loss. QUIC advantage compares when all streams finish under TCP and QUIC in this run; it shows zero when QUIC does not finish sooner.
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 removes cross-stream transport head-of-line blocking; it does not make you immune to a shared network event.
What this exercise helps me practice
This standalone networking exploration is not a result measured from product traffic. It lets me reason about transport behavior by separating stream ordering from connection-level congestion and checking where one loss still affects useful progress.
See the broader engineering brief