How TCP Congestion Control Works: The Invisible Traffic Law That Keeps the Internet From Collapsing

Every video call, file download, and website you have opened this month moved through a mechanism most people never think about. The internet is a shared road network, and if a single sender pushed data as fast as it could, it would flood every junction along the way. TCP's congestion control is the invisible traffic law that prevents exactly that: the sender itself constantly probes how much the path can carry, backs off when it hits the limit, and re-expands when the network has room. It is the reason a billion simultaneous flows can share the same routers without collapsing.

Congestion control is not flow control

The first thing to separate is flow control versus congestion control. Flow control protects the receiver: the destination advertises a receive window (rwnd), and the sender never puts more unacknowledged data in flight than the receiver can absorb. Congestion control protects the network: the sender maintains its own congestion window (cwnd) based on what the path can carry. The effective send window is the smaller of the two. Congestion is an emergent, network-wide condition, and TCP's design decision is that the senders, not the routers, should cooperate to avoid it.

The stakes are concrete. In 1986, Vint Cerf and Bob Kahn showed that under the naive policy of every sender retrying at full rate after a drop, the network enters congestion collapse: nearly every packet is lost, nothing gets through, and throughput falls toward zero even though link capacity is enormous. Congestion control is what keeps the internet above that collapse point.

Slow start: an exponential ramp-up

A brand-new TCP connection has no idea what the path can support. Rather than instantly sending as fast as allowed, it starts with a small congestion window and grows it fast. Modern implementations begin with cwnd of about ten segments; each arriving acknowledgment increases cwnd by one segment, which means it effectively doubles every round-trip. Ten segments become twenty, forty, eighty in four RTTs. The name is misleading: slow start is actually a rapid ramp, just slower than slamming on the gas immediately. It runs until cwnd reaches a threshold called ssthresh or until a sign of congestion appears. Latency matters here: on a 200 ms satellite path, the same ramp takes four times as long as on a 50 ms fiber link, which is why low latency and high bandwidth are different things.

Congestion avoidance: the additive-increase crawl

Once cwnd crosses ssthresh, TCP assumes it is already near the path's capacity and slows its growth: add roughly one segment per round-trip, linearly. This gentle, continuous probe is the classic congestion avoidance phase. The combined behavior is known as AIMD - additive increase, multiplicative decrease. Growth is slow and steady; when loss appears, the window shrinks aggressively. Repeated cycles of linear climb and sudden shrinkage trace the well-known sawtooth pattern on a graph of cwnd over time, the visual signature of a TCP flow continuously testing the edge of available capacity.

Detecting loss without waiting for a timeout

How does the sender know something is wrong? Three duplicate ACKs are the classic signal. If one packet drops, the data behind it keeps flowing; the receiver, unable to acknowledge out-of-order data in-order, re-sends the ACK for the missing segment. Three of those duplicate ACKs tell the sender a loss has occurred while the connection is still healthy - so TCP performs fast retransmit: it resends the lost segment immediately instead of waiting for its retransmission timer. In Reno-style fast recovery, ssthresh is halved, cwnd is cut to ssthresh plus three segments, and transfer continues. A full retransmission timeout is treated as far worse evidence: Tahoe-era TCP drops cwnd back to one segment and restarts slow start entirely. That is why timeouts are much more damaging to throughput than duplicate-ACK losses. The retransmit timer itself is derived from measured round-trip times using an average plus a standard-deviation margin, so a few normal jittery RTTs do not trigger a timeout.

Beyond the sawtooth: CUBIC and BBR

Classic AIMD was tuned for the 1990s. CUBIC, the default in modern Linux, keeps the same phase structure but replaces the linear growth with a cubic function of elapsed time since the last congestion event. Growth is steepest in the middle of the interval and flattens as it approaches the previous peak, producing a smoother curve and better behavior on high-capacity links. BBR, deployed by Google, goes further by changing what to measure. Instead of waiting for losses, it continuously estimates the bottleneck bandwidth and minimum round-trip time, and paces data at their product - the maximum sustainable throughput without filling buffers. On high bandwidth-delay-product paths, such as long-haul and data-center links, BBR routinely delivers several times the throughput of loss-based algorithms, because it stops treating a full buffer as the only signal worth listening to. Its side effect is real: buffer-friendly pacing can squeeze other traffic, so the exact mix of algorithms on a path shapes who gets what.

What this means for you

• Sender-side design: routers stay dumb; the hosts doing the sending carry the traffic-management intelligence.
• Congestion is emergent: no single sender causes it, so no single sender can fully control it - the system only works because everyone backs off.
• Loss is a signal, not a failure: the entire algorithm suite is built on reading drops and ACK patterns as information about capacity.
• Latency and bandwidth differ: the slow-start ramp and BBR's minimum-RTT estimates exist precisely because path delay, not link speed, caps how fast a flow can grow.
• Algorithm choice shapes fairness: CUBIC and BBR make the same physical network behave very differently for different users

Nothing about a fast download is guaranteed by hardware. It is guaranteed by a set of simple feedback rules running in your operating system: probe fast, creep near the edge, halve on loss, restart on timeout. That loop, executed billions of times per second by every device on the planet, is what makes the shared internet behave like a machine instead of a free-for-all - and it is why the moment a path gets crowded, your transfer slows down before the network has to drop a single packet.

Sources: MySimulator: TCP Congestion Control - Slow Start, AIMD & the Cwnd Sawtooth; Speedtest HQ Guide: TCP Slow Start and Congestion Control Explained; WPI Computer Networks course notes: TCP Congestion Control (Kurose & Ross summary).

Corrections: Report an error at corrections@wireshaman.com.