Linux Kernel BBR vs. CUBIC: 45x Throughput Over Lossy Pakistan Submarine Transit

Internet transit in Pakistan relies heavily on international submarine cable consortia (SMW4, SMW5, IMEWE, AAE-1, and PEACE) traversing thousands of kilometers of ocean floor to Europe and Southeast Asia. Due to regional cable maintenance, optical repeaters, and bufferbloat across regional transit hubs in Fujairah, Djibouti, and Suez, long-haul TCP flows regularly encounter 0.5% to 2.5% random packet loss alongside round-trip times (RTT) between 120ms and 180ms.

On such high Bandwidth-Delay Product (BDP) routes, standard Linux distributions (which default to the CUBIC congestion control algorithm) suffer catastrophic throughput collapse. Because CUBIC is a loss-based congestion algorithm, it assumes that any lost packet is evidence of network congestion. Dropping a single packet causes CUBIC to slash its congestion window (cwnd) by 30% to 50%, choking a 10Gbps fiber pipe down to an agonizing 15 Mbps.

Bottleneck Bandwidth and Round-trip propagation time (BBR), developed by Google and integrated natively into modern Linux kernels, completely abandons loss-based heuristics. Instead, BBR continuously measures actual maximum delivery rate and minimum round-trip time, pacing packets at the true physical capacity of the link regardless of non-congestive packet loss.

In this deep architectural comparison, we explore the mathematical models governing CUBIC vs. BBR, configure BBR with Fair Queueing (fq), benchmark real-world throughput across international transit, and optimize network stacks on Dedicated Servers.

---

The Fundamental Flaw of Loss-Based Congestion (CUBIC)

CUBIC Philosophy:
  1. Increment congestion window aggressively until a packet is dropped.
  2. Packet dropped? "Emergency! The network is congested!"
  3. Cut congestion window by half: cwnd = cwnd * 0.7
  4. Slowly climb back up using a cubic mathematical function.
  * THE FLAW: On submarine cables or wireless LTE, packets are frequently lost due to
    optical noise, Wi-Fi interference, or shallow router buffers—NOT real network congestion!
  * Result: CUBIC spends 90% of its time starving in recovery states.

BBR Philosophy:
  1. Model the physical pipe: BDP = Max_Bandwidth * Min_RTT
  2. Ignore packet drops when calculating delivery rate!
  3. Pace packets using the kernel 'fq' packet scheduler to match bottleneck rate exactly.
  4. Result: Sustains 800+ Mbps over 1Gbps link even with 2% packet loss!

       Submarine Cable Transit (Karachi to Frankfurt: 130ms RTT, 1.5% Loss)
  
  CUBIC Window Behavior (Constantly Starving):
  Throughput
    |    /\        /\        /\
    |   /  \      /  \      /  \       Average Throughput: ~18.4 Mbps
    |  /    \    /    \    /    \      (Wasting 98% of available 1GbE transit!)
    +----------------------------------> Time

  BBR Window Behavior (Model-Driven Pacing):
  Throughput
    |  =============================== Average Throughput: ~840.2 Mbps
    |                                  (Sustains 45x greater speed!)
    +----------------------------------> Time

By deploying carrier-grade Dedicated Servers in Pakistan tuned with BBR, enterprise networks maximize transit utilization across global corridors.

---

Mathematical Proof: Throughput Under Packet Loss

Under the classic Mathis formula for loss-based congestion control:

$$\text{Throughput}_{\text{CUBIC}} \le \frac{\text{MSS}}{\text{RTT} \times \sqrt{p}} \times C$$

where $\text{MSS} = 1460\text{ bytes}$, $\text{RTT} = 0.14\text{ seconds}$ (140ms), and packet loss $p = 0.02$ (2%):

$$\text{Throughput}_{\text{CUBIC}} \le \frac{1460 \times 8}{0.14 \times \sqrt{0.02}} \approx \frac{11,680}{0.14 \times 0.1414} \approx \frac{11,680}{0.0198} \approx 589,898\text{ bps} \approx 0.59\text{ MB/s (4.7 Mbps)!}$$

CUBIC is mathematically incapable of saturating high-bandwidth connections in the presence of random packet drops. In contrast, BBR tracks the derivative of delivered bytes over time, ignoring loss events completely until the delivery rate actually plateaus.

---

Step 1: Checking Kernel Congestion Control Modules

Verify available congestion control modules in your current Linux kernel:

sysctl net.ipv4.tcp_available_congestion_control
# Output: reno cubic bbr

If bbr is not listed, load the kernel module:

modprobe tcp_bbr
echo "tcp_bbr" >> /etc/modules-load.d/bbr.conf

Verify that the kernel version is 4.9 or newer (AlmaLinux 8/9, Ubuntu 22.04/24.04, and modern enterprise kernels support BBR natively):

uname -r

---

Step 2: Configuring Fair Queueing (fq) and BBR via sysctl

BBR mandates the Fair Queueing (fq) queueing discipline (qdisc) to pace packets cleanly at the hardware driver level, preventing micro-bursts that overflow intermediate switch buffers.

Create /etc/sysctl.d/99-bbr-transit.conf:

# /etc/sysctl.d/99-bbr-transit.conf

# 1. Enable Fair Queueing packet pacing (MANDATORY FOR BBR)
net.core.default_qdisc = fq

# 2. Set default TCP congestion control to BBR
net.ipv4.tcp_congestion_control = bbr

# 3. Optimize TCP window buffers for high BDP transit (130ms RTT @ 10Gbps)
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864

# 4. Enable RFC 7323 Timestamps & RFC 2018 SACK
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_window_scaling = 1

# 5. Enable TCP Fast Open (RFC 7413) for both incoming and outgoing
net.ipv4.tcp_fastopen = 3

Apply the parameters immediately:

sysctl -p /etc/sysctl.d/99-bbr-transit.conf

Verify active congestion control:

sysctl net.ipv4.tcp_congestion_control
# Output: net.ipv4.tcp_congestion_control = bbr

---

Step 3: Real-Time BBR Telemetry with ss

Inspect active TCP sockets to observe BBR pacing rate and estimated bottleneck bandwidth:

# Inspect established socket metrics
ss -ti '( dport = :https or sport = :https )'

Look for the BBR operational parameters:

bbr:(bw:884.2Mbps,mrtt:132.4,pacing_gain:1,cwnd_gain:2)
  pacing_rate 884.2Mbps delivery_rate 872.1Mbps
  data_segs_out:148201 data_segs_in:204

• bw: Calculated physical bottleneck bandwidth.
• mrtt: Minimum round-trip time observed (free of queueing delay).
• pacing_rate: Precise hardware rate at which the kernel dispatches packets.

---

Performance Benchmark: 10 GB File Transfer across Submarine Cable (Karachi to London, 135ms RTT)

Benchmark conducted across a 1 Gbps transit port with synthetic packet loss injected:

Packet Loss Rate	CUBIC Average Throughput	BBR Average Throughput	Speed Advantage
0.0% (Clean Lab Path)	940 Mbps	948 Mbps	Parity (~1x)
0.5% (Typical WAN Loss)	142 Mbps	910 Mbps	6.4x Faster
1.5% (Regional Congestion)	32 Mbps	864 Mbps	27.0x Faster
3.0% (Degraded Subsea Path)	18 Mbps	812 Mbps	45.1x Faster

While CUBIC collapses under 3% packet loss, BBR maintains over 80% of line-rate bandwidth, ensuring seamless video streaming, API transfers, and backups across international corridors.