Cubic is Linux's default TCP congestion control and has been since 2008. BBR (Bottleneck Bandwidth and RTT, from Google in 2016) is a different model: estimate the bottleneck rate and RTT, pace at that rate. By 2026 it's the default in many production fleets including YouTube. The performance delta is real on long-fat-pipe paths.
Loss-based vs model-based
CUBIC reacts to packet loss as the congestion signal: ramp up until loss, back off. Works when loss correlates with congestion. Fails on lossy wireless networks (false signals) and high-speed paths where buffers absorb early signs of congestion.
BBR's model
Periodically probe the bottleneck bandwidth and RTT. Maintain an estimate. Pace traffic at min(bandwidth × time_since_last_ack, configured cap). Avoids filling buffers; throughput stays high even on slightly lossy networks.
Where BBR wins
Long fat pipes (high bandwidth × delay product): BBR uses bandwidth CUBIC can't. Slightly lossy links: BBR doesn't mis-attribute loss to congestion. Bufferbloated middleboxes: BBR avoids filling them.
Where to be careful
Sharing a bottleneck with CUBIC flows: BBR is more aggressive, takes more bandwidth. Fair sharing isn't guaranteed across algorithms. In a controlled environment (your servers to your CDN): fine. On the public internet, watch BBR's neighbors.
Enabling on Linux
sysctl net.ipv4.tcp_congestion_control=bbr. Plus net.core.default_qdisc=fq (FQ-CoDel queueing discipline; BBR depends on pacing). Test on staging first; gather throughput and latency metrics before broader rollout.