TCP congestion control

Why the internet nearly ground to a halt in 1986

In October 1986, a Berkeley network link fell from 32 kbit/s to about 40 bit/s. Router queues overflowed, senders resent the dropped packets, and the resends jammed the queues further. This is called congestion collapse.

Congestion control is TCP's fix: each sender caps its congestion window (cwnd), the data it may have sent but not yet seen acknowledged. About one window goes out per round trip (RTT), so rate ≈ cwnd ÷ RTT.

The sender can't see the routers, so it guesses from what comes back. Steady ACKs mean there is room, so it grows the window. A missing packet usually means some router's queue overflowed, so it shrinks the window.

TCP congestion control

Google runs its own algorithm, BBR, for YouTube and Google Search

Every TCP connection you open runs congestion control, and the operating system picks the algorithm. Linux and Android default to CUBIC, which regrows the window after a loss along a cubic curve.

In 2016, Google put its own algorithm, BBR, on google.com and YouTube. BBR doesn't wait for loss. It measures the bottleneck bandwidth and the shortest RTT, then sends at about that rate, which keeps router queues short.

TCP congestion control

Each sender speeds up slowly, then halves when a packet goes missing

A new connection starts small (10 packets on modern systems) and uses slow start: it doubles the window every RTT, so it finds the available speed in a few round trips.

After a loss, or once it passes a set threshold, it switches to AIMD (additive increase, multiplicative decrease): add one packet per RTT, halve on loss. If ACKs stop entirely and a timeout fires, it restarts slow start from a tiny window.

Halving drains a full queue fast and makes senders share fairly. Flows at 30 and 10 packets halve to 15 and 5, then both regrow at +1 per RTT. Their gap shrinks from 20 to 10, so repeated cycles even them out.