TCP Congestion Control
Same loss event, dramatically different recovery shapes.
How TCP congestion control works
The slow start problem
TCP starts at cwnd=1 because you don't know the network capacity. It doubles each RTT to probe aggressively — 1, 2, 4, 8, 16 — until something breaks. This exponential growth finds the available bandwidth fast, but it will overshoot.
The sawtooth
AIMD — additive increase, multiplicative decrease — is provably fair and efficient. Grow linearly, cut on loss. The sawtooth isn't a bug; it's the algorithm working. Every sender converges to its fair share through these oscillations.
Tahoe vs Reno
Triple duplicate ACKs mean "a packet was lost but the network is still delivering." A timeout means "the network might be broken." Tahoe treats both the same — crash cwnd to 1 and start over. Reno is smarter: on dup ACKs, it halves cwnd and keeps going (fast recovery). It only crashes to 1 on a timeout.
Why Cubic
On fat long pipes, Reno's linear increase takes forever to recover. A 10 Gbps link at 100ms RTT has a bandwidth-delay product of ~125,000 packets. After a single loss, Reno needs 62,500 RTTs (over an hour) to get back. Cubic uses a cubic function of time since last loss — it recovers quickly, plateaus near the previous max, then probes cautiously beyond it.