How TCP Congestion Control Algorithms CUBIC and BBR Differ in Managing Internet Latency and Throughput

Network engineers face a fundamental divide in how to push data across the internet without melting the connection. On one side, the traditional loss-based approach assumes that a dropped packet means the network is full, demanding an immediate slowdown to prevent collapse. On the other side, a newer model-based philosophy argues that packet loss is a noisy signal, especially on modern wireless links, and that senders should instead measure the actual speed of the pipe and pace their packets accordingly.[6]

For anyone managing a server, a video streaming platform, or a high-speed network, the choice between these two philosophies dictates the throughput floor and latency ceiling of the application. The default algorithm on most operating systems, CUBIC, works exceptionally well on clean local networks but struggles on lossy connections. Switching a server to Bottleneck Bandwidth and Round-trip propagation time (BBR) requires only a single configuration change in the Linux kernel, yet it can double the throughput of a video stream on a degraded 4G link without touching the application code.[6]

To understand the divide, one must look at how Transmission Control Protocol (TCP) historically managed traffic. TCP uses a congestion window to limit the total number of unacknowledged packets that may be in transit end-to-end. CUBIC, which became the default in Linux, Windows, and Apple stacks, finds the network's capacity by sending data faster and faster until it sees a packet loss.[2][5]

When a drop occurs, CUBIC sharply reduces its sending window and then uses a cubic polynomial function to quickly ramp back up to the previous maximum before flattening out to probe for more capacity. This mathematical approach allows CUBIC to handle congestion with significantly greater complexity compared to the linear functions employed by older algorithms like Reno.[2]

The limitation of this loss-based design is that it fills network buffers until they overflow. "Loss happens before congestion for network gear with shallow buffers," notes ThousandEyes in their 2024 analysis of path quality. On links with deep buffers, CUBIC causes "buffer bloat"—a phenomenon where packets sit in long queues, adding hundreds of milliseconds of latency to the connection.[3]

Furthermore, on wireless or satellite links where packets are routinely lost to interference rather than congestion, CUBIC misinterprets the drop and unnecessarily throttles the connection. This behavior treats every packet drop as a sign of network collapse, which is a flawed assumption on modern 4G and 5G networks.[3][6]

Google introduced BBR to break the reliance on packet loss. Standardized as an Internet Engineering Task Force (IETF) draft, BBR actively probes the network to build a model of two parameters: the bottleneck bandwidth (the maximum data rate the path can support) and the round-trip time (the baseline delay when the network is empty).[1]

Instead of waiting for a buffer to overflow, BBR paces its packets to match the exact capacity of the bottleneck link. By doing so, it attempts to keep the transmit rate at the level just before network buffers begin to queue packets, effectively eliminating buffer bloat while maximizing throughput.[1]

The performance difference becomes stark when network conditions degrade. In a 2024 ThousandEyes benchmark, both algorithms achieved similar baseline throughputs on a clean symmetric network—804.6 Mbps for CUBIC and 868.5 Mbps for BBR. However, when engineers introduced a 1 percent packet loss rate, CUBIC's throughput collapsed to 235.51 Mbps.[3]

BBR, ignoring the random loss, maintained 794.06 Mbps—retaining over 91 percent of its baseline capacity. That represents a 70.3 percent difference in achieved throughput between CUBIC and BBR under identical loss conditions. This resilience makes BBR highly attractive for video streaming and mobile delivery, where maintaining a high throughput floor is critical for user experience.[3]

Despite its throughput advantages, BBR is not a universal solution. Researchers have documented fairness issues when BBR flows compete directly with CUBIC flows on the same bottleneck link. Because BBR ignores packet loss and continues to push data at the modeled bandwidth, it can starve loss-based algorithms that back off aggressively.[4][5]

Additionally, BBR has historically favored flows with longer round-trip times, allocating them more bandwidth than competing short-RTT flows. The MDPI journal published research on optimizing BBR through a "Pacing Gain Model" to address this exact fairness disparity, noting that adjusting the pacing gain according to the RTT can improve BBR's intra-protocol fairness by 46 percent.[4]

The networking community continues to refine these models to ensure equitable bandwidth allocation. BBRv3 has been integrated into recent Linux 6.x kernels, bringing updates that improve coexistence with CUBIC and reduce packet retransmissions. These iterative improvements are necessary before model-based algorithms can fully replace loss-based ones on the public internet.[1][4]

The transition from loss-based to model-based congestion control represents a structural shift in internet architecture. While CUBIC remains the robust, universally deployed standard for clean environments, BBR provides a necessary alternative for the increasingly wireless and heterogeneous public internet. The decision rests on the specific network path: a pure local area network may see little benefit from BBR, but for global content delivery, pacing to the bottleneck is replacing probing to the drop.[6]