Congestion Control: Slowing Down When the Network Is Full

Congestion control stops senders from pushing more data into the network than it can carry. The sender keeps a congestion window, its own estimate of how much data can be in flight without overloading the path. It starts small, grows while everything is acknowledged, and shrinks sharply when packets are lost, because on the internet a lost packet usually means a queue somewhere overflowed.

Think of a driver who speeds up while the road is clear and brakes hard at the first sign of a jam. The comparison breaks in one place: the driver sees the traffic, and TCP sees nothing. It infers congestion only from loss, or in some newer algorithms from rising delay.

The pattern has two phases.

Slow start. A new connection does not know the path, so it begins with a small window, ten segments on most systems today, and doubles it each round trip as acknowledgements arrive. Despite the name, growth is fast; what is slow is the start.

Backing off and probing. When a segment is lost, the sender cuts the window, by half in the classic algorithm, and then grows it slowly, one segment per round trip, testing for spare capacity. CUBIC, the default on Linux, cuts by less and regrows along a curve, but follows the same idea.

Two consequences reach applications directly. A new connection cannot use the full speed of the path at once; a large download starts slowly and speeds up over several round trips. And loss on a busy path slows the sender far more than the missing data itself, because every loss also cuts the window.

The sender obeys two limits together. It may send no more than the smaller of the congestion window, which protects the network, and the receiver's window, which protects the receiver.

So a transfer that starts slowly and speeds up is congestion control at work, and a reused connection that has already grown its window avoids paying for it again.