How Do TCP CUBIC and BBR Probe Bandwidth Safely?

TCP congestion control algorithms like CUBIC and BBR discover available network bandwidth by gradually increasing their sending rate while monitoring network feedback such as packet loss, round-trip time, and delivery rate. By bounding the amount of unacknowledged data in flight and backing off when queues begin to build or packets drop, these algorithms avoid overwhelming bottleneck links and prevent congestion collapse.

Preventing Congestion Collapse

Congestion collapse occurs when a network becomes so overloaded that routers drop packets faster than endpoints can retransmit them, causing useful throughput (goodput) to plummet toward zero. Early TCP implementations avoided this through conservation of packets, ensuring a new packet is only injected into the network when an old packet leaves, signaled by an acknowledgment (ACK). Modern algorithms like CUBIC and BBR build on this foundation by regulating how aggressively they probe for extra capacity.

How CUBIC Probes Bandwidth

CUBIC is a loss-based congestion control algorithm that adjusts its congestion window (\(W\)) as a cubic function of the elapsed time (\(t\)) since the last packet loss event:

\[W_{\text{cubic}}(t) = C(t - K)^3 + W_{\max}\]

Here, \(W_{\max}\) is the window size just before the last loss, \(C\) is a scaling constant, and \(K\) is the time required for the window to grow back to \(W_{\max}\):

\[K = \sqrt[3]{\frac{W_{\max}(1 - \beta)}{C}}\]

where \(\beta\) is the multiplicative decrease factor (typically \(0.7\)).

This cubic curve gives CUBIC two key properties that prevent collapse:

  • Concave growth below \(W_{\max}\): After a packet loss, CUBIC quickly recovers toward the last known safe rate, then slows down and flattens out near \(W_{\max}\) to avoid immediately causing another drop.
  • Convex growth above \(W_{\max}\): If no loss occurs after passing the plateau, CUBIC assumes more bandwidth is available and accelerates its probing. Once a packet is dropped, it immediately reduces its window by \(\beta\), draining the bottleneck queue before probing again.

How BBR Probes Bandwidth

BBR (Bottleneck Bandwidth and Round-trip propagation time) takes a model-based approach rather than waiting for packet loss. It continuously estimates two parameters: the maximum recent delivery rate (\(BtlBw\)) and the minimum round-trip time (\(RTprop\)). The optimal amount of data in flight, known as the bandwidth-delay product (\(BDP\)), is:

\[BDP = BtlBw \times RTprop\]

BBR operates in a state machine to probe without saturating buffers:

  • Startup: BBR doubles its sending rate each round trip to quickly find \(BtlBw\). Once the delivery rate stops growing, it enters the Drain state to clear the queue it just created.
  • ProbeBW: BBR spends most of its time here, cycling its pacing gain (for example, \(1.25\times\), \(0.75\times\), and \(1.0\times\) of \(BtlBw\)). The brief \(1.25\times\) phase probes for newly available bandwidth, while the \(0.75\times\) phase drains any excess queue that formed.
  • ProbeRTT: Periodically, BBR reduces its congestion window to a small fixed value (such as 4 packets) to drain queues completely and measure an updated \(RTprop\).

Why Probing Remains Safe

Both algorithms prevent congestion collapse by coupling their probing directly to network feedback. CUBIC relies on packet loss as a hard ceiling and spends most of its time near equilibrium, while BBR uses explicit pacing and periodic queue draining to keep buffers shallow. Because neither algorithm continues to increase its sending rate blindly when queues grow or packets drop, the network remains stable even as flows compete for bandwidth.