CUBIC was designed in 2005 by Sangtae Ha and Injong Rhee to improve TCP performance on high-bandwidth, high-RTT links. It replaces the classic linear growth of AIMD with a cubic function of time since the last congestion event, which means it grows aggressively at first, then slows as it approaches the previous capacity. After a loss the window is multiplied by 0.7 (less harsh than the classical 0.5), and the cubic curve restarts. The result is fast recovery on long fat pipes and acceptable fairness with older TCP variants.
CUBIC became the Linux default in 2007 and the de-facto industry standard for TCP congestion control. Windows, macOS and iOS shipped CUBIC by 2013. Most CDN servers still run CUBIC for general HTTP traffic in 2026. Its weakness is bufferbloat: CUBIC keeps growing until it sees loss, and on links with deep buffers it fills them all up before detecting congestion, adding hundreds of milliseconds of queueing delay.
For streaming, CUBIC is a fine default for VOD over fixed broadband. For live and low-latency streaming it is increasingly being replaced by BBR on the server side, especially for CDN origins and edge caches serving cellular networks. The choice is operationally invisible to viewers; CDN dashboards and synthetic probes are the only place the difference shows up.
The book · Volume 2 of 7
Video Streaming: A Complete Guide to Video Delivery: From Network Protocols and Transport to Ingest, HLS, and MPEG-DASH
CUBIC is the default TCP congestion control on most servers, so it shapes how video segments reach viewers whether you chose it or not. Volume 2 covers CUBIC in detail with congestion control, BBR, TCP versus UDP, QUIC and HTTP/3, and what the network does to a stream. Written by Nikolay Sapunov, CEO at Fora Soft.
Is CUBIC or BBR the better congestion control for your video servers?
We will benchmark CUBIC and BBR on your delivery paths and recommend which one to run, with measured throughput. 250+ video products shipped since 2005.
