BBR (Bottleneck Bandwidth and Round-trip Propagation Time)

Classic loss-based congestion control (Reno, CUBIC) treats packet loss as the primary congestion signal and grows the congestion window until a drop occurs, which reliably fills any buffer in the path to capacity before backing off. On deep buffers this produces bufferbloat: latency balloons well before loss is observed. BBR instead builds an explicit model of the path using two independently tracked state variables: BtlBw (the maximum observed delivery rate over a windowed max-filter) and RTprop (the minimum observed RTT over a windowed min-filter). The sending rate is derived from BtlBw * RTprop, the estimated bandwidth-delay product, and the sender paces packets onto the wire at that rate rather than bursting a window’s worth of data at once.

BBR cycles through four states: Startup (exponential probing to find BtlBw, similar in growth rate to slow start but exited on plateau detection rather than loss), Drain (deliberately draining the queue built during Startup’s overshoot), ProbeBW (steady state, spending most cycles at the estimated rate with periodic short probes above it to detect bandwidth increases), and ProbeRTT (periodically dropping the in-flight window to a minimum to get a clean RTprop sample, since queuing elsewhere would otherwise inflate the RTT estimate indefinitely). This model-based approach makes BBR largely indifferent to random, non-congestive loss — relevant on wireless links, satellite paths, or noisy long-haul WAN links where CUBIC would misinterpret loss as congestion and collapse its window unnecessarily.

The architectural catch is fairness and deployability. BBR does not use packet loss as a primary signal, so on a shared shallow-buffer bottleneck with concurrent CUBIC flows, BBR can capture a disproportionate share of bandwidth because CUBIC backs off on loss while BBR does not. BBRv1 was notably aggressive here; BBRv2 introduces loss-rate and ECN awareness to cap in-flight bytes and improve co-existence with loss-based traffic. Correct deployment also requires the fq (fair-queue) qdisc on Linux, since BBR pacing depends on the kernel spacing packets at sub-RTT granularity — running BBR under pfifo_fast defeats pacing and produces bursty, lossy behavior indistinguishable from a poorly tuned CUBIC flow. RTT-based fairness is another edge case: flows with shorter RTTs cycle through ProbeBW faster and can out-compete longer-RTT flows for the same bottleneck, a problem visible in multi-region replication topologies with asymmetric path lengths.

In practice, BBR is the default or optional congestion control on Google’s production stack (Google Cloud networking, YouTube, and gRPC/QUIC transports), where it was engineered to counter bufferbloat across CDN-to-eye-ball paths and long WAN links between datacenters. For platform teams, adopting BBR is a network-layer tuning decision with system-wide blast radius: it changes retransmission behavior, interacts with qdisc configuration, and shifts fairness dynamics on shared links, so it should be validated against the actual mix of concurrent congestion-control algorithms on the bottleneck link rather than assumed as a drop-in throughput win.