TCP Congestion Control: Slow Start, AIMD & the Cwnd Sawtooth

The congestion window: TCP's speed dial

TCP sends multiple segments without waiting for each individual acknowledgement, and the congestion window (cwnd) is what limits how many bytes can be in flight at once. Throughput follows directly: throughput ≈ cwnd / RTT. Push cwnd too high for the network's actual capacity and a bottleneck buffer fills and starts dropping packets; keep it too low and you leave bandwidth unused. TCP has no direct way to measure available bandwidth, so classic algorithms treat packet loss itself as the signal that cwnd has grown too large.

Slow start: exponential probing

A new connection starts in slow start, where cwnd doubles every round-trip time — exponential growth, despite the name, chosen because a brand-new connection has no idea what the path can support and needs to ramp up quickly rather than crawl. Once cwnd crosses a threshold (or a loss occurs), TCP switches to congestion avoidance, where cwnd grows only linearly, adding roughly one segment per round-trip — a far more cautious probe for any remaining spare capacity.

AIMD and the sawtooth

Once in congestion avoidance, classic TCP variants apply Additive Increase, Multiplicative Decrease (AIMD): grow cwnd by roughly one segment per round-trip, and the instant a loss is detected, cut it sharply — Reno halves cwnd, while older Tahoe drops all the way back to 1 segment and restarts slow start entirely. Plotted over time, Reno's repeated slow linear climb followed by a sudden halving traces the well-known sawtooth pattern, a visual signature of a TCP flow continuously testing the edge of available capacity and backing off when it finds it.

Slow start:           cwnd(t+RTT) = 2 · cwnd(t)          (until threshold or loss)
Congestion avoidance: cwnd(t+RTT) = cwnd(t) + 1 MSS       (linear probing)
Loss detected (Reno): cwnd → cwnd / 2                      (multiplicative decrease)
Timeout (Tahoe):      cwnd → 1 MSS, restart slow start

Beyond loss-based control: CUBIC and BBR

Reno and Tahoe treat any packet loss as a congestion signal, which works poorly on modern high-bandwidth, high-delay links where a single loss event can needlessly halve a connection carrying gigabits per second. CUBIC, the Linux default since 2006, grows cwnd along a cubic function of time since the last loss, recovering capacity faster on long "elephant" flows. Google's BBR takes a different approach entirely, modelling the path's actual bottleneck bandwidth and round-trip time directly instead of reacting to loss after the fact — on high bandwidth-delay-product networks this can deliver 2-10× better throughput than loss-based algorithms, because it stops treating a full buffer as the only signal worth listening to.

Frequently asked questions

Try it live

Everything above runs in your browser — open TCP Congestion Control, switch between Tahoe, Reno and CUBIC, and watch the cwnd sawtooth trace out as a bottleneck buffer fills and drops packets.