This TCP Congestion Algorithm Could Speed Up Your High-Latency Links (with a twist)

2025-08-08

What is a TCP Congestion Control Algorithm?

Every time data is sent over the Internet using TCP, the protocol needs to figure out how fast it can go without overwhelming the network. That’s the job of a congestion control algorithm.

These algorithms regulate the rate at which data is transmitted based on feedback from the network. If the network is congested and packets are being dropped or delayed, the algorithm slows down. If there’s room to send more data, it speeds up.

Think of it as cruise control for your internet traffic. The goal is to find the right speed that keeps everything flowing smoothly — without causing bottlenecks, excessive delays, or dropped packets.

Different algorithms use different signals to detect congestion. Some rely on packet loss, others watch latency trends, and newer ones try to model the path entirely. This is where the difference between classic approaches like Cubic and newer ones like BBR becomes important.

Why congestion control still matters

Every byte on the Internet travels through buffers of limited size. When senders push data faster than the path can drain, packets queue, drop, or both. Congestion control algorithms decide how fast to send so that everyone gets a fair share without overwhelming the network. Over the years we have moved from Reno to New Reno, from Vegas to Westwood, and today, most Linux servers ship with Cubic as the default.

A refresher on Cubic

Cubic replaced Reno in Linux 2.6. It relies on packet loss to detect congestion. The window of in-flight data grows following a cubic function of time, which allows quick recovery after loss while remaining friendly to peers. Cubic is mature, easy to reason about, and well-studied. Because it reacts to drops, it can fill buffers (extra queueing delay) yet it shares bandwidth fairly with other Cubic or Reno flows.

BBR comes to disrupt

BBR (Bottleneck Bandwidth and Round Trip time) changes the rule of the book. Instead of watching for loss, it continuously models the link. It measures the best bandwidth it has seen along with the lowest round-trip time, and targets the product of the two (the BDP) as its operating point. The result is shorter queues and lower latency on long fat pipes, especially when packet loss is caused by noise, not congestion.

BBR is now part of the Linux kernel (v4.9 and later). A proposed v2 improves fairness when multiple BBR flows compete with Cubic, but it is still experimental.

Cubic vs BBR at a glance

Recent tests show that on a loopback path with random delay, Cubic sustained around 3 Gbps while BBR averaged about 1.7 Gbps and exhibited larger variance. Yet on lossy long-haul links such as satellite broadband, BBR often cuts tail latency by double-digit percentages.

Quick guide: enabling BBR on Ubuntu (for a lab only)

Warning: These steps alter global networking. Use them on a non-production host or a test VM, and roll back when done.

Step 1: Check your kernel

uname -r     # needs 4.9 or newer; 5.15+ recommended

Step 2: Load the Fair Queuing scheduler

sudo modprobe sch_fq

Step 3: Enable BBR

echo "net.core.default_qdisc=fq" | sudo tee -a /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Step 4: Verify

sysctl net.ipv4.tcp_congestion_control   # should print bbr

Step 5: Run traffic tests

Use tools like iperf3 to observe throughput and latency.

Step 6: Revert

Replace bbr with cubic in the file above, run sudo sysctl -p, and unload sch_fq if desired.

Advanced: To experiment with BBR v2 you must compile or install a kernel with tcp_bbr2 support and set net.ipv4.tcp_congestion_control=bbr2. This remains a moving target and is not advised for service hosts.

Practical advice

• Use Cubic for websites, APIs, and ordinary file transfers.
• Consider BBR when you own both ends of a connection with a very large bandwidth-delay product. Think inter-data-center replication, remote backup across oceans, or satellite links.
• Always benchmark. BBR shines only when queues build up; on short local paths, it may under-utilise capacity.
• Mix with care. A single BBR flow can monopolise a small buffer and hurt older algorithms. Use traffic shaping or deploy BBR on all peers of the same path.

Last Words…

BBR is a leap toward model-driven congestion control, promising low delay and high goodput on tough links. Yet it trades predictability and compatibility for speed. Keep Cubic as the default in everyday workloads, and reserve BBR for workloads that really need very high throughput over very long latency networks.