CUBIC is standardized; BBR must be evaluated by version and implementation
Separate the CUBIC RFC, BBR draft, and measurement evidence; check kernel configuration, queues, and fairness.
Publication & corrections: infostoa · Editorial standards
Individual author and specialist reviewer information is not provided for this article.
Different models and congestion signals
TCP congestion controllers adjust sending behavior to use path capacity while responding to congestion. CUBIC uses a time-based cubic window-growth function after congestion; RFC 9438 updated its specification as an IETF Standards Track RFC in 2023. Google’s BBR family estimates bottleneck bandwidth and minimum round-trip time to model delivery. It is inaccurate to say BBR simply ignores loss or removes delay and loss on every network. Behavior depends on BBR version and implementation, loss and ECN handling, and path conditions.
Standards status and versions
RFC 9438 specifies CUBIC and describes its adoption in several TCP stacks. The IETF BBR document listed here is an Internet-Draft, not an RFC or Standards Track specification. A draft revision should not be assumed to match the code shipped by an operating system. Results for BBRv1 must not be presented as results for BBRv2 or BBRv3. Check which controller is actually included in the product, kernel distribution, and build being deployed.
Enabling it on Linux
The Linux kernel must include the relevant implementation, and available algorithms can be checked with sysctl net.ipv4.tcp_available_congestion_control. On a kernel that supplies BBR, an administrator can select it with net.ipv4.tcp_congestion_control=bbr; scope and defaults still depend on distribution and socket settings. Google’s BBR FAQ describes a sender-pacing path using the fq queuing discipline, so changing the algorithm name alone does not establish an end-to-end throughput improvement. Other operating systems have their own TCP stack controls.
What an expert measurement found
A reproducible emulation study by Benedikt Jaeger, Dominik Scholz, Daniel Raumer, Fabien Geyer, and Georg Carle (2019) reported fairness problems for the BBR implementation they evaluated when it competed with other congestion controllers. The authors measured interactions with CUBIC, Reno, Vegas, and Illinois as well as fairness among BBR flows. This is evidence about specific versions and configurations from that study, not a verdict on every current BBR release. It supports retesting with the competing algorithms, RTTs, bottleneck, buffer, and loss conditions stated.
Compare the right outcomes
Do not choose a controller on throughput alone. Measure RTT latency, queue occupancy, loss and retransmission, fairness among concurrent flows, and results for flows with different RTTs under the same bottleneck. BBR bandwidth probing can create transient queues, while CUBIC’s delay and fairness behavior also varies with implementation and path. The expert perspective here is the named authors’ reproducible study, not a performance guarantee for a current operating system.