Skip to content

SYSTEM Cited by 1 source

BBRv3

BBRv3 is the third iteration of BBR (Bottleneck Bandwidth and Round-trip propagation time) — Google's model-based congestion-control algorithm. Unlike loss-based CCAs (CUBIC, Reno), which read packet loss as the primary congestion signal, BBR continuously estimates the path's bottleneck bandwidth and minimum RTT and paces sends so bytes-in-flight ≈ the bandwidth-delay product — aiming to avoid building a queue at the bottleneck rather than responding to the queue overflowing.

Why Cloudflare runs it

Cloudflare's 2026-05-12 quiche post closes with:

"Our CCA efforts go beyond loss-based algorithms: we also use quiche's modular congestion control design to experiment with and tune our model-based BBRv3 implementation, now enabled for a growing percentage of our QUIC deployments." (Source: sources/2026-05-12-cloudflare-when-idle-isnt-idle-how-a-linux-kernel-optimization-became-a-quic-bug)

Two structural motivations for moving from CUBIC to BBR at Cloudflare-edge scale:

  • Bufferbloat resistance. Loss-based CCAs on modern networks with large intermediate buffers will fill those buffers before detecting loss, paying seconds of queueing latency on top of baseline RTT. BBR's bandwidth-delay-product model keeps bytes-in-flight near the path's actual carrying capacity, not the buffer depth.
  • Recovery after loss. The 2026-05-12 post is itself a canonical instance of the loss-based-CCA family's recovery dynamics being subtle, corner-case-prone, and expensive to debug. Model-based CCAs avoid reasoning about "did the network drop my packet?" as the primary control signal.

BBR versions in the wild

  • BBRv1 (2016, Google). Aggressive bandwidth-probing; well-known to be unfair to loss-based CCAs sharing the same bottleneck (starves them).
  • BBRv2 (2019–). Addressed v1's fairness problems by adding loss + ECN signals as secondary inputs; ran in Google production on youtube.com + google.com traffic.
  • BBRv3 (2023–, current). Further-refined model-based core with tuned behaviour for shallow-buffer networks + better coexistence with loss-based traffic. The version Cloudflare names as running in quiche deployments.

Architectural position in quiche

quiche's modular CCA design is what makes BBRv3 deployable alongside CUBIC without forking the library. The relevant post calls this out as the structural property that lets Cloudflare "experiment with and tune" the BBRv3 implementation while CUBIC remains the default. Canonical wiki instance of concepts/user-space-congestion-control + pluggable CCA interface: because QUIC runs entirely in user space, shipping a second CCA is a library change, not a kernel upgrade — the deployment rhythm compresses from "wait for kernel distros to pick it up" to "quiche release cadence."

What this wiki page is not

This page is a short stub at the level of Cloudflare's 2026-05-12 mention. A full canonical BBR / BBRv3 page — with the bandwidth- probing phases (STARTUP / DRAIN / PROBE_BW / PROBE_RTT), the bandwidth estimator, the RTprop estimator, the pacing-rate derivation, and the fairness trade-offs — will be added when the wiki ingests a full BBR / BBRv3 retrospective (Google / Cloudflare deep-dive). The Cloudflare New standards / congestion-control post is the cited anchor for further detail.

Seen in

Last updated · 542 distilled / 1,571 read