Congestion collapse

Why can a network carry less traffic in total the harder everyone tries to push data through it?

A link has a capacity. Offer it less than that and it delivers what you offered; offer it more and the obvious expectation is that it delivers its capacity and drops the rest. Saturation, in other words — a curve that rises and then flattens.

What actually happens on a network can be worse than flat. Push harder and the total amount of useful data arriving at the far end goes down, sometimes catastrophically. Jacobson's account of the October 1986 episode between Lawrence Berkeley Lab and Berkeley — a path that fell from 32 kbit/s to 40 bit/s, a thousandfold — is the canonical case. I am recalling that figure rather than deriving it, so treat it as the one number here worth checking. What has to be true of a system for pushing harder to deliver less?

Ask first what the flat curve assumes. It assumes a dropped packet cost the network nothing. Is that true? A packet dropped at the fifth hop has already consumed transmission time on four links and buffer space in four routers. That work is spent and produces nothing. So even at the plateau, some of the network's capacity is burned carrying packets that will die before arrival — already a reason for the curve to bend down rather than flatten.

But that alone is gradual. The collapse needs something sharper. What else changes when queues fill?

Delay. A router absorbs a burst by queueing it, which is what buffers are for — but a full buffer means every packet waits behind everything ahead of it, and round-trip time rises, perhaps by an order of magnitude. What is the sender doing during that wait? Holding a timer. If no acknowledgement arrives in the expected time, it concludes the packet is lost and sends it again.

Follow that. The packet was not lost; it was queued. The retransmission is a second copy of data already in flight. It joins the same queues, lengthens them further, and pushes delay up again — which causes more timers to expire, on more connections, producing more duplicates. Each copy consumes capacity; only one of them can be useful. If the average packet is transmitted k times, useful throughput is capacity divided by k, and k is being driven upward by the very congestion it worsens. That is the loop, and it is genuinely a positive feedback: nothing in it pushes back.

Now test the account by trying to break it. If congestion by itself caused collapse, then a protocol that never retransmits should collapse too. It does not. A live video stream over UDP under the same overload simply loses frames and degrades — the goodput curve flattens rather than falling off a cliff, because a lost packet is never resent. That is the discriminating case, and it points the blame squarely at the retransmission feedback rather than at congestion as such. Nagle named the failure mode in RFC 896 in 1984 for a related reason: small packets and needless retransmissions filling a network with copies.

So what breaks the loop? Look at what it needs. It needs a sender that treats delay as loss, so the first fix is an adaptive timeout — estimate the round-trip time and its variation from observation, and back off exponentially when retransmitting, so a sender under stress sends copies more slowly rather than faster. It needs senders that offer the same load regardless of evidence, so the second is to make loss itself a signal: halve the sending rate on loss, and grow it only slowly while things work. And it needs a sender that begins at full speed, so the third is to start small and probe upward. Those three — Karn's timeout handling, additive-increase/multiplicative-decrease and slow start — turned the collapse of the late 1980s into an engineering memory.

There is a piece worth flagging as still argued over. Treating loss as the congestion signal means buffers must fill before anyone reacts, which is why oversized buffers produce persistently high delay — bufferbloat. Delay-based and model-based schemes react earlier, and whether they compete fairly with loss-based ones is an open, actively contested question.

Two neighbouring pictures need separating from this one. Phantom traffic jams, which form on an open motorway from reaction lag alone, do reduce flow past a critical density — but no driver answers a delay by spawning a second copy of their car. That loop runs through spacing and reaction time, not duplication, so throughput sags rather than collapses. And the routing story, in which each router forwards on local knowledge with no central controller, explains how packets find their way; it says nothing about how many should be sent. Congestion control is the missing half, and it lives in the endpoints, not the routers.

Be precise, too, about what "collapse" names. Total packets moved does not fall — the links stay busy, often busier than ever. What falls is goodput: bytes that arrive, in order, sent only once, and useful to the application. A network in collapse is working at full stretch and delivering almost nothing, which is what makes it so disorienting to diagnose from a utilisation graph.

Finally, this is a collective-action problem in technical costume. Each sender retransmitting faster is behaving rationally on its own information — it genuinely cannot tell a queued packet from a lost one. The restraint that fixes it is unenforced and pays off only if nearly everyone practises it.

• Bufferbloat: why generous router buffers made delay worse while hiding the loss signal.
• How explicit congestion notification lets a router say "slow down" without discarding anything.

Every term the collection defines is gathered in the glossary.