Should BBR be the default TCP Congestion Control Protocol?
Josue Abreu, Paul Bergeron, Sandhya Aneja
TL;DR
This paper evaluates whether BBR should be the default TCP congestion control by synthesizing experiments and prior work across Internet, data centers, Ethernet, wireless, and satellite networks. It uses a criterion-based framework to compare BBRv2/v3 with loss-based and ECN-based schemes, focusing on throughput, latency, fairness, robustness, and deployment practicality. Key findings show BBR achieves high throughput across environments and can coexist with Cubic, but incurs higher latency and jitter, with fairness highly environment-dependent; data-center and lossless Ethernet contexts reveal limitations. The practical implication is workload-driven protocol selection, with BBR favored for bulk transfers and latency-insensitive tasks, while other schemes may be preferable in latency-sensitive or lossless settings. The work underscores the ongoing evolution of BBR and the need for protocol evolution to extend its benefits to diverse network domains.
Abstract
In this research, we investigate the feasibility of adopting the Bottleneck Bandwidth and Round-trip propagation time (BBR) protocol as the default congestion control mechanism for TCP. Our central question is whether BBR, particularly its latest iterations, BBRv2 and BBRv3, can outperform traditional TCP variants such as Reno and Cubic across diverse networking environments. We evaluated performance trade-offs in Internet, data center, Ethernet, wireless, and satellite networks, comparing BBR against protocols including DCTCP, DCQCN, TIMELY, HPCC, Swift, and congestion control schemes designed for low-Earth orbit satellite networks, using both experiments and previous studies. Our findings show that BBR consistently achieves high throughput across all environments, with especially strong performance and fairness in scenarios involving homogeneous BBR flows or high bandwidth Internet paths. Experiments with Google and other websites over a 100~Mbps home network further confirm BBR's superior performance and its ability to co-exist with Cubic flows. In another experiment on the Marist campus (1--10~Gbps network), we observed its latency characteristics compared to Cubic. Moreover, a controlled evaluation between protocols reveals that BBR achieves the highest throughput ($\approx 905$~Mbps) but introduces higher latency ($\approx 0.79$~ms) and jitter ($\approx 4.2$~ms). In contrast, Reno and Cubic deliver balanced performance with lower latency and moderate jitter. Vegas prioritizes minimal latency and jitter at the cost of reduced throughput. These results demonstrate the strength of BBR to handle bulk transfers and bandwidth-intensive applications. However, they also emphasize the significance of workload-driven protocol selection in latency-sensitive environments.