Skip to content

CONCEPT Cited by 1 source

BBR congestion control

Definition

BBR (Bottleneck Bandwidth and Round-trip propagation time) is a model-based congestion-control algorithm introduced by Google in 2016 (ACM Queue article). Unlike older algorithms like CUBIC and NewReno, BBR does not infer congestion from packet loss. Instead it estimates the bottleneck bandwidth and the minimum RTT of the path and paces itself to match them.

This makes BBR robust to loss sources that are not congestion — notably radio-channel noise, interference, and handover on wireless networks.

Canonical framing on the wiki

Zalando's 2024-06 post identifies BBR as the 5G-capable CC algorithm and the future-dominant algorithm for internet traffic:

"Only BBR exhibited the lowest round trip time values among all possible physical failure scenarios and can satisfy the typical 5G requirements. [...] BBR algorithm has increased its share in terms of the practical implementation and it can be expected to become the dominant algorithm in the future." (Source: sources/2024-06-17-zalando-next-level-customer-experience-with-http3-traffic-engineering)

The driving case is radio-access-network characteristics: BBR's model-based estimation handles the RF loss / queuing-delay profile that CUBIC/NewReno misinterpret as congestion.

Key mechanics

  • Bottleneck bandwidth estimate (BtlBw) — the max data rate observed over a sliding window.
  • Minimum RTT estimate (RTprop) — the min RTT observed over a longer window.
  • Pacing — send rate = BtlBw; window = BtlBw × RTprop.
  • Probing phases — BBR periodically tries higher rates (ProbeBW) and minimum rates (ProbeRTT) to re-measure both.
  • Loss not a congestion signal — loss is a side observation; BBR adjusts only if loss is high enough to suggest the model is wrong.

Versions

  • BBR v1 — the original 2016 algorithm. Known issue: unfair coexistence with CUBIC flows; can dominate available bandwidth at the expense of competing TCP-CUBIC flows.
  • BBR v2 — Google's 2019 iteration adding explicit loss-rate and ECN-aware fairness improvements.
  • BBR v3 — 2022+ iterations focused on datacenter and high-speed path tuning.

User-space deployment (see concepts/user-space-congestion-control) is what makes BBR version iteration viable without kernel patches — a critical reason Zalando highlights BBR as the future default.

Why 5G changes the CC calculus

On 5G mid-bands:

  • Loss is not congestion — RF noise, interference, and handover all cause loss independent of queue occupancy.
  • Blockages on mmWave — buildings, vehicles, trees, human bodies cause intermittent loss patterns.
  • Handover causes RTT spikes and loss bursts — both look like congestion to CUBIC / NewReno.

CUBIC's response in all these cases is to halve the window. BBR's response is to check whether BtlBw has actually changed before adjusting. The difference is measurable: Zalando cites BBR maintaining low RTT where CUBIC / NewReno collapse.

Adoption

  • Google — BBR is default for Google's production services.
  • Cloudflare, Meta — adopted BBR / BBR-family variants in production.
  • QUIC standard — explicitly leaves CC algorithm open to the implementation; BBR is a common choice in QUIC stacks, alongside CUBIC.

Seen in

Last updated · 501 distilled / 1,218 read