TCP congestion control

A new connection knows nothing about the path, so TCP has to slowly probe the network to determine the available capacity ¹. In slow start the window grows by up to one segment for every ACK ², roughly doubling each round trip, and it ends when the window passes ssthresh or a loss is seen ³. Then congestion avoidance adds about one full-sized segment per round trip ⁴, and keeps going until congestion is detected ⁵.

TCP reads a lost packet as a sign of congestion ¹. After 3 duplicate ACKs, fast retransmit resends the missing segment without waiting for the retransmission timer ²³, ssthresh drops to half the data in flight ⁴, and the window is set to ssthresh ⁵: that drop and the slow climb after it are the sawtooth. If the timer fires instead, the window falls to 1 full-sized segment and slow start begins again ⁶.

The halving above is classic Reno. CUBIC, the default in the Linux, Windows and Apple stacks, grows the window along a cubic curve instead of a straight line, and cuts it to 0.7 of its size where Reno uses 0.5 ¹²³. Google's BBR stops treating loss as the signal and considers how fast the network is delivering data ⁴, because loss-based control overreacts, halving the sending rate upon packet loss ⁵.