TCP Congestion Control (Reno / Cubic / BBR)
TechniqueNetworking and OSSeniorStaffUpdated
Algorithms that decide how fast TCP sends. Loss-based (Reno, Cubic) treat packet loss as congestion; model-based (BBR) measures bottleneck bandwidth and round-trip time (RTT) directly.
When to Use TCP Congestion Control (Reno / Cubic / BBR)
Anywhere you tune kernel TCP for high bandwidth-delay-product links (CDN egress, cross-region replication). Cubic is the Linux default; BBR shines on lossy long-fat networks (LFNs) where Cubic backs off too aggressively.
In Practice
Google switched YouTube and google.com egress to BBR around 2016 and saw 4-14 percent throughput gains on average across regions, with much larger wins on lossy mobile links. Set with
sysctl net.ipv4.tcp_congestion_control=bbr.How TCP Congestion Control (Reno / Cubic / BBR) Comes Up in Interviews
Scenario
Your CDN serves users in Africa over high-RTT, mildly lossy links. Cubic's throughput collapses on these paths because it treats every random loss as congestion. What do you switch to?
Switch the kernel's congestion control to BBR. BBR models the bottleneck bandwidth and minimum RTT instead of reacting to loss, so random non-congestive drops do not cripple it.
BBR is not strictly better; on shared links with Cubic flows it can be slightly unfair, and very early versions had issues with Wi-Fi. BBRv2 and v3 address most of that.