Watch a network connection decide how fast to go.

That run, one cycle at a time

Every number below is read out of the run in the chart above — not an illustration of it. Follow it once and the rest of the site is the same loop under different conditions.

1. 010 s

   The sender starts with 10 segments in flight — 14.1 KiB. It has no idea what the link can take, and nothing will tell it.

2. 02141 ms

   So it doubles every round trip — 10, 20, 40 — and after 3 round trips it is at 40 segments. That is "slow start", and it is only slow for the first moment.

3. 0386 + 86

   Two limits it cannot see. The wire itself holds 86 segments (122.1 KiB, the BDP) — that is capacity × round trip, and it is how much can be in transit at once. Past that, packets wait in the bottleneck's buffer, which holds another 86. Nothing is lost yet; the queue just gets longer, and so does the round trip.

4. 048310 ms

   The buffer is full, so the next packet to arrive is thrown away. This is the only message the network ever sends back, and it is a silence rather than a message.

5. 058412 ms

   The sender does not find out until 102 ms later. That is one round trip as it stands right then — 50.0 ms of wire plus about 51.9 ms waiting in the queue it just filled — because the loss is inferred from duplicate ACKs, which cannot come back sooner. A fuller buffer makes this feedback slower, which is the whole case against big buffers. Then it cuts: 174 segments down to 87, roughly half. Everything it knows about the network is this stale.

6. 06× 4

   From there it climbs by one segment per round trip until it overshoots again. That happened 4 times in 30 seconds, and those are the teeth. Nobody designed the shape — it is this loop, plotted. Segment counts are exact here only because every segment in this model is one MSS; a real stack varies.

New to this?

How a connection finds its speed

1. 01

   Send a little, then more

   A new connection starts cautiously and doubles how much it sends every round trip. Within a second it is going far faster than it began — and usually faster than the link can take.

2. 02

   The slow point fills up

   Somewhere on the path is the narrowest link. Packets arriving faster than it can forward them wait in a queue. The queue is why your latency climbs while a download runs.

3. 03

   A packet is dropped, and that is the message

   When the queue is full the next packet is thrown away. The sender notices the gap and cuts its rate — usually in half. That drop is the only feedback the network gives, and the whole system is built on it.

4. 04

   Climb, drop, climb, drop

   Nobody designed the shape that comes out. Repeat the loop and the rate traces a sawtooth, forever hunting a ceiling it is never told. Everything else on this site is a consequence of it.

Where to go

Roughly in order. Each page answers one question and shows the run it used to answer it.

1. 1/jejakTraceWatch one connection find its speedRun a simulation →
2. 2/antreanQueue & AQMWhy a bigger buffer makes things worseRun a simulation →
3. 3/bandingCompareFive algorithms, one identical linkRun a simulation →
4. 4/adilFairnessTwo connections, one link — who gets whatRun a simulation →

Scenarios

Each one is a configuration that demonstrates a single named phenomenon.

Why the shapes on this site can be believed

Anyone can draw a convincing sawtooth. This one is produced by scheduling, queueing, dropping and acknowledging individual packets on a virtual clock — and then checked against four predictions published independently of it, before any of it is shown to you.

These are other people’s results, not self-checks. A simulator that reproduces four of them is one whose surprising outputs can be trusted — and the surprising outputs are the reason to build it.