congestion collapse

Picture a narrow doorway in a panicking crowd. The more people shove, the more tightly they jam, until almost nobody gets through even though everyone is pushing as hard as they can. Congestion collapse is the network version of that doorway: a state where the offered load is huge but the useful work delivered drops toward zero, because the network is busy carrying traffic that will never actually arrive.

Here is the mechanism. When routers are overloaded, their buffers fill and they start dropping packets. A sender that loses a packet retransmits it — but if the sender does not slow down, it just adds yet more packets to an already-jammed network, causing still more drops and still more retransmissions. Packets that do squeak through often arrive too late, after their sender has already given up and resent them, so the network spends its precious capacity delivering duplicate copies that get thrown away. The link is 100 percent busy yet delivers almost no new, useful data. This is not hypothetical: in October 1986 a stretch of the early Internet between Berkeley sites collapsed from a normal 32 kbps down to about 40 bps — a thousandfold drop — which is what spurred Van Jacobson to invent the slow-start and congestion-avoidance algorithms TCP still uses.

The cure is exactly congestion control: senders must treat loss as a signal to slow down, not a reason to retransmit faster. Modern TCP's additive-increase/multiplicative-decrease behaviour, slow start, and timers with backoff all exist to keep the network out of this trap. Collapse is rare today precisely because nearly every sender obeys those rules — which is also why a flood of senders that ignore them (some attacks, or badly written software) remains dangerous.