Congestion Control
TCP Congestion Control
How TCP decides how fast to send — probing for capacity, then backing off when the network pushes back. It is the invisible negotiation that lets millions of connections share the internet without it grinding to a halt.
Congestion control is the family of algorithms TCP uses to regulate its sending rate. A connection cannot know in advance how much capacity the path has, so instead of transmitting at full blast — which would overwhelm the network — it feels its way: it starts slow, speeds up while data keeps flowing cleanly, and pulls back the moment it senses congestion. This constant self-adjustment is what keeps the shared internet stable when countless flows compete for the same links.
Slow start: the cautious opening
Every TCP connection begins in slow start. The sender puts only a small amount of data "in flight," then roughly doubles it each round trip as acknowledgements come back, rapidly probing how much the path can carry. The doubling continues until the connection detects loss or reaches a threshold, at which point it switches to a gentler growth phase. A practical consequence: very short transfers finish before slow start ramps up, which is why a tiny download never hits your full line speed and why latency strongly shapes how quickly a connection reaches full throughput.
Detecting congestion: loss and delay
How does TCP know the network is congested? Two signals:
- Packet loss: when buffers overflow, packets are dropped. Traditional algorithms treat a lost packet as the cue to slow down.
- Rising delay: queues filling up increase round-trip time before any loss occurs. Newer algorithms watch this to act earlier.
On detecting congestion, the sender reduces its sending window, then cautiously grows it again — the endless "ramp up, back off" cycle that shares capacity among competing flows.
CUBIC vs BBR
| Algorithm | Congestion signal | Strength |
|---|---|---|
| CUBIC | Packet loss | Long-time Linux default; robust and well understood |
| BBR | Measured bandwidth & delay | High throughput without filling buffers; better on lossy/long paths |
CUBIC waits for loss and reacts; BBR builds a model of the path's bandwidth and round-trip time and paces itself to that, avoiding the buffer-filling that causes bufferbloat. Both are widely deployed, and the choice affects how a connection behaves on imperfect links.
Why this matters to your speed
Congestion control explains several everyday observations: why a download "warms up" rather than hitting full speed instantly, why a lossy or high-latency link underperforms its raw capacity, and why a single big transfer can momentarily add lag to everything else. It also clarifies the difference between congestion control (what the sender does to find a safe rate) and the router-side QoS/SQM tools that manage queues locally — both fight congestion, but from opposite ends of the connection.