This post recounts the reproduction of the BBR congestion control paper's key loss-tolerance results, conducted by Stanford students Luke Hsiao and Jervis Muindi for the CS244 course, as originally discussed on zhichai.net.
Background
Traditional loss-based TCP congestion control (e.g., CUBIC, the Linux default) treats packet loss as a signal of congestion, sharply reducing sending rate when packets are dropped. This works well on wired networks with negligible loss, but collapses in lossy environments such as wireless and cellular links, where random loss is misinterpreted as congestion.
BBR (Bottleneck Bandwidth and Round-trip propagation time), proposed by Google engineers in 2016, takes a different approach: it continuously estimates the bottleneck bandwidth (BtlBw) and minimum RTT (RTprop), operating near the theoretical optimum point identified by Leonard Kleinrock in 1979. Google reported 2x–25x throughput gains on its B4 wide-area network.
The Reproduction Study
Hsiao and Muindi set out to reproduce Figure 8 of the original BBR paper, which plots throughput versus random packet loss rate. Their setup:
- Ubuntu 16.04 VM with Linux kernel 4.11.1 (built-in BBR module)
- Mahimahi network emulator for precise control of bandwidth, RTT, and random loss
- Custom Python TCP client/server traffic generators
- Unlimited router buffers, TCP send/receive windows enlarged to 6.25 MB, flows of 30–120 seconds
- Core result confirmed: At very low loss rates, CUBIC slightly outperforms BBR (the initial BBR implementation was deliberately simple). As loss rate increases, BBR stays close to the ideal throughput curve (1 − loss rate) × link rate, degrading noticeably only at ~45% loss, while CUBIC collapses at far lower rates.
- Minor differences from the original: BBR tolerated higher loss (45% vs. 20% in the paper), possibly due to differences between Mahimahi's and netem's loss models; Neal Cardwell confirmed the simplified initial congestion window and ProbeRTT contributed to slightly worse low-loss performance. Enlarging the TCP window was essential—otherwise BBR used only ~80% of the bandwidth.
- Multi-algorithm comparison: BBR beat BIC, RENO, VEGAS, and WESTWOOD at non-negligible loss rates. BIC and WESTWOOD were runners-up; VEGAS was too conservative and RENO outdated.
- Bandwidth sweep (0.01–100 Mbps): The BBR–CUBIC gap shrinks at low bandwidth, because loss-based algorithms tolerate more loss when the bandwidth-delay product is small. At 10 Kbps the two are nearly equal; on modern broadband BBR's advantage is large.
- RTT sweep (2–500 ms, 120-second flows): CUBIC tolerates more loss at lower RTT (smaller BDP), but BBR maintains high utilization across all RTT values, improving further with longer flows.
- Real-world validation: Replacing simulated queues with a real Verizon LTE trace, BBR continued to substantially outperform CUBIC, confirming the laboratory results on genuinely lossy cellular links.
Key Findings
Why It Matters
The reproduction validates that congestion-based control can dramatically improve throughput in lossy networks—relevant to video buffering, cloud gaming, and mobile browsing. The students open-sourced all experiment code, contributing to reproducibility in networking research.
References
1. Cardwell, N., Cheng, Y., Gunn, C. S., Yeganeh, S. H., & Jacobson, V. (2017). BBR: Congestion-Based Congestion Control. Queue, 14(5), 20-53. 2. Hsiao, L., & Muindi, J. (2017). ReBBR: Reproducing BBR Performance in Lossy Networks. Stanford CS244 Reproducing Network Research Blog. 3. Reproducing Network Research Blog, Stanford University: https://reproducingnetworkresearch.wordpress.com/ 4. Mahimahi Network Emulator: http://mahimahi.mit.edu/ 5. rebbr GitHub Repository: https://github.com/jervisfm/rebbr