The Internet's First Major Traffic Jam
In the mid-1980s, the internet was a small, academic community, but it was growing fast. Like a town that suddenly becomes a city without building new roads, its infrastructure was groaning under the strain. The core problem was that computers were designed
to send data as fast as they could, without any awareness of the network's capacity. Before 1986, the protocols had rules to keep a fast sender from overwhelming a slow receiver, but there was no effective mechanism to stop senders from overwhelming the network itself. Each computer acted in its own self-interest, pushing as much data as possible. When packets of information were inevitably dropped by overloaded routers, the computers were programmed to do the most logical, yet ultimately self-destructive, thing: immediately resend the lost packets, adding even more traffic to the already-clogged system.
When the Network Ground to a Halt
In October 1986, this simmering problem boiled over into a full-blown "congestion collapse." The connection between Lawrence Berkeley National Laboratory and UC Berkeley—a mere 400 yards apart—saw its data throughput plummet from 32,000 bits per second to just 40 bits per second. That's a reduction of nearly 1,000-fold. It was as if a superhighway had been reduced to a single-lane dirt path clogged with abandoned cars. The network was full of packets furiously flying around, but no useful data was getting through. It was the internet's first existential crisis. Many feared the entire project couldn't scale and was doomed to fail under its own weight. The internet had worked before simply because there weren't enough users to break it. By 1986, that was no longer true.
The 'Politeness' Protocol
Enter Van Jacobson, a researcher at Lawrence Berkeley National Laboratory. He realized the core issue wasn't a technical flaw but a behavioral one. The computers were all shouting at once and no one was listening. His solution, developed with Mike Karels, was brilliantly simple: teach the computers some manners. The result was a new set of rules for the Transmission Control Protocol (TCP) built around a concept called Additive Increase, Multiplicative Decrease (AIMD). Think of it like a conversation. You start speaking at a normal volume (additive increase), slowly getting louder to see what the room can handle. The moment someone says, "I can't hear you because it's too loud" (a dropped packet), you don't just stop talking; you immediately cut your volume in half (multiplicative decrease) and start ramping up slowly again. This prevents you from immediately shouting again and ensures everyone gets a chance to be heard.
A Social Contract for Machines
This "be polite" strategy was a game-changer. Instead of each computer acting selfishly, AIMD created a decentralized, cooperative system. It established a social contract where every device agreed to back off aggressively at the first sign of trouble and then cautiously ramp up. This approach ensures fairness; over time, multiple data flows using this method will naturally converge on an equal share of the available bandwidth. It solves the "tragedy of the commons," where a shared resource is destroyed by individuals acting in their own rational self-interest. By using packet loss as a signal for congestion, TCP was designed to constantly probe the network's limits without catastrophically exceeding them. This dynamic, self-regulating system allowed the internet to scale without central management.
Why It Still Matters Today
Van Jacobson's 1988 paper outlining these ideas became one of the most important in networking history. The principles of AIMD, slow-start, and using packet loss as a feedback signal are still at the heart of the modern internet. While dozens of newer, more sophisticated algorithms like CUBIC and BBR have been developed, they are all descendants of that original philosophy. Every time you stream a movie without buffering, join a video call, or simply browse the web, you are benefiting from this 40-year-old solution born from a near-total collapse. It’s the invisible, cooperative engine that prevents the internet from grinding to a halt, ensuring the information superhighway remains a robust and reliable public utility for billions of users.
