Part 4 · 2 chapters · ~12 min

Congestion Control

Congestion collapse and why it is controlled at the sender, slow start and the initial window, additive increase and multiplicative decrease, Reno and CUBIC, BBR's model-based approach, the bandwidth-delay product, bufferbloat, and what congestion control means for application design.

8

Windows that grow and shrink

code
bandwidth-delay product: how much data must be in flight to fill a link
  100 Mbit/s × 150 ms (Lagos ↔ US East) = 12.5 MB/s × 0.15 s ≈ 1.9 MB in flight
  a 64 KB window would cap throughput at 64 KB / 0.15 s ≈ 430 KB/s, whatever the link speed
sysctl net.ipv4.tcp_congestion_control      # cubic or bbr (Linux)
CONGESTION CONTROL OVER ONE CONNECTION
the congestion window grows, a loss halves it, and it grows again
RTT 1cwnd 10 segments (initial)
swipe the figure sideways, or tap expand for full screen
1/5
the problem
Without congestion control, every sender would push as fast as its link allows and routers in the middle would drop most packets (congestion collapse, seen on the 1980s internet).
senders must not overload the pathcongestion collapse happened in 1986
9

Bufferbloat and application design

Bufferbloat: oversized buffers in routers and modems absorb congestion instead of dropping packets, so loss-based algorithms keep filling them and latency balloons (a video call stutters while a download runs). Active queue management (CoDel, fq_codel) and BBR reduce it.

implications for applications
  1. Reuse connections: avoid repeated handshakes and slow start.
  2. Send fewer, larger requests on high-latency links; batch.
  3. Compress and trim payloads: fewer round trips of window growth.
  4. Prefer HTTP/2 or HTTP/3 for many small requests (one connection, one window).