TCP Cubic vs TCP BBR Performance Comparison: Simulation with NS-3

1. Introduction

In modern computer networking, Congestion Control is vital for effective data transmission. As the Internet evolves with WANs, satellite links, and high-speed wireless, traditional algorithms like TCP Cubic face challenges such as high latency and random packet loss.

This research simulates and compares TCP Cubic (the Linux default) and TCP BBR (developed by Google) using NS-3 (v3.43). The goal is to evaluate their performance metrics — throughput, RTT, and fairness — in harsh network conditions.

2. Technical Overview

TCP Cubic

Cubic is a loss-based algorithm. It adjusts its congestion window ($cwnd$) using a cubic function of the time since the last congestion event.

• Signal: Packet loss.
• Pros: Stable, widely deployed, fair in low-RTT environments.
• Cons: Suffers from Bufferbloat, performs poorly in Long Fat Networks (LFNs) with random packet loss.

TCP BBR

BBR (Bottleneck Bandwidth and Round-trip propagation time) is a model-based algorithm. It continuously estimates the maximum bandwidth ($BtlBw$) and minimum RTT ($RTprop$).

• Signal: Increases in RTT and decreases in delivery rate.
• Pros: Minimizes latency, maximizes throughput, robust against non-congestive packet loss.
• Cons: Can be aggressive against loss-based flows.

---

3. Simulation Methodology

Network Topology

We use a standard Dumbbell Topology to create a bottleneck between two gateways.

Dumbbell Topology Figure 1: Simulation Setup with NS-3

Configuration:

• Access Links: 100Mbps, 1ms delay.
• Bottleneck Link: 10Mbps, random delay (Mean 50ms, Var 10ms).
• Packet Loss: Scenarios from 0% to 5%.
• MTU: 1500 bytes.

---

4. Results & Performance Analysis

4.1. Throughput Comparison

In environments with increasing packet loss, BBR maintains near-line speed, while Cubic's performance collapses.

Throughput Comparison Figure 2: Throughput vs. Packet Loss Rate

At 5% packet loss, BBR outperforms Cubic by ~25 times, demonstrating its resilience to random loss.

BBR Improvement Chart Figure 3: Improvement factor as loss increases

4.2. RTT & Latency Analysis

BBR effectively targets the BDP (Bandwidth-Delay Product), avoiding the queue buildup that causes Bufferbloat in Cubic.

Delay Comparison Figure 4: Average Delay Comparison

RTT Evolution Figure 5: RTT Stability over time

In the 0% loss scenario, Cubic forces the RTT up to 542ms (filling the buffer), while BBR stays near the optimal 86ms.

4.3. Congestion Window Evolution

Cubic's $cwnd$ fluctuates wildly due to its sensitivity to loss. BBR's $cwnd$ remains stable around the estimated BDP.

Cwnd Evolution Figure 6: Congestion Window Traces

4.4. Fairness Evaluation

Cubic remains the "fairer" protocol when competing for bandwidth, but at a massive cost to throughput in lossy conditions.

Fairness Comparison Figure 7: Jain’s Fairness Index (Cubic: 0.51 vs BBR: 0.46)

---

5. Analysis: Why BBR Dominates?

The primary reason for BBR's superiority is its definition of congestion.

• Cubic sees a single lost packet as a signal to cut its speed by 30%.
• BBR treats packet loss as a transient error. It only slows down if the delivery rate drops or queuing delay (RTT) increases, indicating real bottleneck saturation.

By using a windowed max filter to estimate bandwidth, BBR "filters out" the noise of random packet loss, allowing it to maintain a high sending rate where Cubic would otherwise stall.

---

6. Conclusion & Recommendations

Based on our NS-3 simulations, we conclude:

1. BBR is the superior choice for modern Internet traffic, especially for international links, mobile networks, and satellite communications where random loss is frequent.
2. Cubic remains relevant for local datacenter environments where loss is rare and fairness is the highest priority.

Deployment Recommendations

---

This research was conducted as part of the Advanced Computer Networking course at VNU-HCM University of Science by Ngô Tấn Tài.