The 1986 Congestion Collapse: When the Internet Nearly Choked on Its Own Success
The 1986 Internet congestion collapse showed how TCP retransmissions could amplify packet loss until busy links carried almost no useful data, leading to slow start and congestion avoidance.
The Internet discovered that retransmission could make congestion worse
By the mid-1980s, the growing Internet had reached a counterintuitive failure mode: overloaded links caused packet loss, TCP endpoints interpreted loss as a reason to retransmit, and those retransmissions added still more traffic to already congested paths. John Nagle had warned in 1984 that IP and TCP could enter congestion states in which useful throughput collapsed even while hosts kept sending.[2] The network was not simply busy. It could spend most of its capacity carrying packets that would be dropped, duplicated, or retransmitted again.
More sending did not mean more progress
A system can be fully utilized while accomplishing almost no useful work. Congestion collapse made that distinction painfully concrete: link occupancy rose as application throughput fell.
October 1986 provided the dramatic measurement that changed TCP
Van Jacobson and Michael Karels later described an October 1986 episode in which throughput between Lawrence Berkeley Laboratory and UC Berkeley fell from roughly 32 kilobits per second to about 40 bits per second, even though the sites were only a few network hops apart.[1] Their investigation showed that TCP implementations were injecting traffic too aggressively and recovering poorly from loss. The result was not a defect in one router. It was emergent behavior produced by many independently correct endpoints interacting through shared queues.
The failure lived between layers and machines
No single sender possessed enough information to see the whole congestion state. The transport protocol needed a feedback rule that let endpoints infer shared network stress from packet loss and acknowledgments.
Slow start changed how a TCP connection entered the network
One key answer was slow start. Instead of beginning a connection by filling the advertised receiver window immediately, TCP would begin with a small congestion window and increase the amount of outstanding data as acknowledgments proved that the path could carry it. RFC 2001 later documented slow start as one of the four intertwined algorithms developed from Jacobson’s work.[4] The idea converted startup from an assumption about capacity into an experiment. Each connection had to earn the right to send faster.
Capacity became something to discover
The sender no longer treated receiver memory as the only meaningful limit. It maintained a second window representing what the network itself appeared able to sustain.
Congestion avoidance made loss a signal to reduce pressure
Jacobson’s congestion-avoidance algorithm used packet loss as evidence that the network had crossed a safe operating point. Rather than immediately resending at the same rate, TCP reduced its congestion window and then increased cautiously.[1] This created an additive-increase, multiplicative-decrease style of feedback that let many flows share a bottleneck without continuously forcing it into collapse. The algorithm was important because it did not require every router to coordinate with every host. Endpoints could adapt using signals already available in ordinary TCP traffic.
The cure was distributed restraint
The Internet survived growth not by giving one controller authority over every flow, but by teaching endpoints a common discipline for backing off when shared infrastructure showed stress.
Host requirements eventually made congestion control mandatory
RFC 1122 incorporated congestion-control expectations into the requirements for Internet hosts, helping convert a research response into normal TCP behavior.[3] This is a recurring path in infrastructure engineering: a dramatic operational failure reveals a missing invariant, experimental fixes demonstrate a workable approach, and standards then turn that approach into a baseline obligation. Congestion control became part of what it meant to implement TCP correctly, not an optional performance optimization.
Fast retransmit and fast recovery refined the response to isolated loss
Later TCP work distinguished between a path that is truly congested and one that has lost an individual segment while data continues to flow. RFC 2001 documented fast retransmit and fast recovery so a sender could repair a likely missing segment without collapsing all the way back to the slowest startup behavior.[4] This shows how reliability mechanisms mature: the first priority is preventing catastrophe, then the protocol learns to respond more precisely so safety does not unnecessarily destroy performance.
Modern TCP still carries the architecture born from the collapse
RFC 5681 standardized the core concepts of slow start, congestion avoidance, fast retransmit, and fast recovery for later TCP implementations.[5] Newer congestion-control algorithms have changed how capacity is estimated and how quickly senders probe for bandwidth, but they still operate inside the basic insight established in the 1980s: endpoints must treat the network as a shared, dynamic resource. Sending rate cannot be determined solely by application demand or receiver capacity.
Why the 1986 congestion collapse belongs in software-failure history
The 1986 congestion collapse belongs in software history because the Internet nearly defeated itself through positive feedback. Packet loss caused retransmission, retransmission increased congestion, and congestion caused still more loss until useful throughput approached zero. The fix was not a larger link or a central scheduler. It was a change in endpoint software that made TCP responsive to network conditions. That episode remains a model for distributed engineering: when independent actors share scarce infrastructure, local attempts to recover can amplify global failure unless every participant follows feedback rules that reward restraint.
Works Cited
- 01Jacobson — Congestion Avoidance and Control ee.lbl.gov
- 02RFC 896 — Congestion Control in IP/TCP Internetworks rfc-editor.org
- 03
- 04
- 05RFC 5681 — TCP Congestion Control rfc-editor.org
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.