Understanding TCP BBR congestion control
Most congestion control algorithms treat packet loss as the signal to slow down. On modern networks with deep buffers, that heuristic breaks: the pipe stays full, latency climbs, and throughput collapses. BBR takes a different approach — it builds a model of the path (bottleneck bandwidth and round-trip propagation time) and paces packets to match it.
Enabling BBR on Linux
On kernels 4.9 and later it only takes two sysctl knobs:
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbrVerify with sysctl net.ipv4.tcp_congestion_control and confirm the qdisc with tc qdisc show. BBR needs pacing, which is why the fq scheduler matters.
When it helps most
- High bandwidth-delay product links (cross-region traffic)
- Lossy paths where CUBIC backs off too aggressively
- Long-lived flows: backups, media, file sync
Caveats
BBR is not magic. It competes for buffer space like everything else, and early versions were unfair to CUBIC flows sharing a bottleneck. Measure with your real workload — iperf3, retransmit counters and RTT histograms tell you more than any blog post (including this one).