TCP BBR vs CUBIC: The Battle for Throughput
From Loss-Driven Throttling to Model-Based Velocity: Redefining Network Saturation.
Congestion Control Simulator
Model the deterministic behavior of CUBIC and BBR across variable bandwidth, RTT, and packet loss profiles.
Network Parameters
BDP (KB)
Efficiency Gain
Time Saved
Recommended
Congestion Control Comparison
Key Insights
Bandwidth-Delay Product
1000 KB
High BDP favors BBR
Time Savings
-4.3s
BBR advantage
Loss Impact
0.00ms
RTT penalty (CUBIC)
"BBR excels in high-BDP, low-loss networks typical of AI clusters. CUBIC degrades with loss."
The Legacy of Loss: The Reactionary Era
In the context of the Border Gateway Protocol (BGP) and modern Internet engineering, a "Congestion Event" has historically been defined by the overflow of a router's buffer. This is a **Reactionary Paradigm**. When a router is overwhelmed, it drops a packet. The TCP sender (CUBIC or NewReno) detects this drop via duplicate ACKs and interprets it as a command to "Slow Down"—effective for 100Mbps Ethernet, but catastrophic for 400Gbps AI clusters.
Loss-based congestion control algorithms operate on a binary logic: **Success = No Loss, Failure = Loss**. This creates the infamous "Sawtooth" pattern of network throughput. The throughput ramps up until a drop occurs, collapses by 50% (multiplicative decrease), and then slowly crawls back. In high-latency environments, this "slow crawl" wastes gigabits of bandwidth every second.
CUBIC Growth Equation (RFC 8312)
As defined in **RFC 8312**, CUBIC uses the time since the last congestion event to scale the window. While CUBIC is more aggressive than its predecessors, its fundamental reliance on loss makes it blind to **Bufferbloat** and random wireless noise.
The Physics of Bandwidth-Delay Product (BDP)
To understand why CUBIC fails AI training jobs, one must master the physics of the **Bandwidth-Delay Product (BDP)**. The BDP defines the total number of bits that can be "in flight" on the wire at any single point in time. It is the capacity of the pipe.
In high-radix fabrics, 0.01% random packet loss causes CUBIC to throttle permanently to <10% of theoretical maximum.
BBR ignores random drops, maintaining window size based on delivery rate, preserving throughput during noise events.
The Bufferbloat Crisis
"A full buffer is a slow buffer. If your pings spike during a download, you aren't suffering from 'Slow Internet,' you are suffering from a failure of congestion control logic."
As defined in the **Jim Gettys** research on **Bufferbloat**, loss-based algorithms like CUBIC must fill a buffer to the point of "Standing Waves" in order to detect that the limit has been reached. In modern data center switches with shallow buffers (e.g., Broadcom Jericho 2), CUBIC results in constant micro-drops. In older core routers with massive 1-2GB buffers, CUBIC results in "Puffy Latency," where pings jump from 10ms to 800ms during a backup job.
BBR solves this by **Pacing**. Instead of bursting packets back-to-back at physical wire speed, BBR spreads packets out over the RTT. It sends exactly one packet's worth of data for every packet it receives. This "Conservation of Flow" ensures the switch buffers remain empty, maintaining sub-millisecond tail latency even at 99% link utilization.
BBR Architecture: Modeling the Pipe
Google's BBR (Bottleneck Bandwidth and Round-trip propagation time) does not look at packet loss. Instead, it looks at the **Physical Physics** of the path. It continuously estimates two variables:
RTprop (Minimum RTT)
The time it takes a packet to travel the path with zero queueing delay—limited only by the speed of light in glass.
BtlBw (Max Bandwidth)
The maximum rate at which the bottleneck router can reliably receive and forward packets.
Efficiency Taxonomy
BBR v2: The Convergence of Model and Fairness
BBR v1 was a massive success for Google's internal B4 network, but it was "unfair" on the public internet—it would often drown out CUBIC flows by refusing to back off during loss. BBR v2 addresses this through four critical engineering updates:
ECN Awareness
Reacts to Explicit Congestion Notification (ECN) flags from routers before bits are dropped.
Improved Coexistence
Uses a better "Target Inflight" calculation that allows CUBIC flows to grab their share of the buffer.
Loss-Informed Pacing
While still model-based, it now uses high loss rates (e.g., >2%) as a signal of reaching a severe physical bottleneck.
Fast Recovery
Refined ProbeRTT phases that minimize throughput dips during model re-calibration.
Role in AI Infrastructure
Goodput Efficiency Model
At 400Gbps speeds, the overhead of CUBIC's sawtooth cycle results in a "Goodput Efficiency" of roughly **72%** over long-haul links. BBR maintains a steady **98%+**, representing a multi-million dollar ROI for GPU cluster utilization.
Expert FAQ
Technical Standards & References
"You are our partner in accuracy. If you spot a discrepancy in calculations, a technical typo, or have a field insight to share, don't hesitate to reach out. Your expertise helps us maintain the highest standards of reliability."
Contributors are acknowledged in our technical updates.