BBR Congestion Control
BBR models the delivery rate and round-trip time of a path to maximize throughput while keeping queues short, replacing loss-based congestion control that misreads wireless and buffered links.
Definition
BBR is a congestion control algorithm that estimates bottleneck bandwidth and minimum RTT, then paces packets at the estimated bandwidth-delay product rather than reacting to loss. It maintains high throughput on paths where loss is not congestion, and avoids the bufferbloat latency that loss-based algorithms induce by filling queues.
Context and scope
Deployed on high-traffic public endpoints, video streaming servers, and QUIC stacks where mobile radio loss and deep buffers distort loss signals. Requires kernel or library support and interacts with fairness on mixed-traffic paths.
Common misconceptions
- BBR is just a better loss detector — it does not use loss as its primary signal at all
- BBR eliminates latency — it bounds queue occupancy, but propagation and access latency remain
- BBR is always fair to CUBIC flows — early versions could grab disproportionate share on some paths
Anti-patterns
- Enabling BBR on a server without pacing support and creating burst-induced loss for everyone
- Assuming BBR fixes bufferbloat caused by oversized buffers on the client access side
- Comparing single-flow benchmarks and concluding fleet-wide behavior without mixed-traffic tests
Related concepts
Related examples
Authoritative source
What it is
Classic algorithms treat loss as congestion and shrink the window on any drop. On wireless links, drops are radio noise; on buffered paths, loss appears only after queues overflow and latency has already collapsed. BBR instead measures delivery rate and minimum RTT and sends at the product of the two.
How it works
The sender periodically probes for higher bandwidth and for lower RTT in alternating phases, maintaining a maximal model of the path. Pacing spaces packets to the target rate rather than emitting window-sized bursts. BBRv2 refined fairness, loss response, and ECN handling based on deployment experience.
When to use it
Public services on lossy or mobile access networks see both throughput and tail-latency gains. QUIC implementations often default to BBR variants because the transport is user-space and pacing is easy. Long-lived bulk flows benefit most; request-response traffic sees smaller deltas.
Pitfalls
Interaction with loss-based flows needs testing; BBRv1 could starve CUBIC on shared shapers. Shallow buffers that rely on drop to signal overload interact differently with a rate-based sender. Measure retransmits, goodput, and p99 latency together to confirm the change helped.