Congestion control is the feedback loop that keeps a transport from filling every router buffer between sender and receiver. The classical model — additive increase, multiplicative decrease (AIMD) — grows the sending rate slowly until packet loss is detected, then halves it. CUBIC (RFC 8312, February 2018) is a refinement of AIMD that recovers more aggressively after loss, and has been the default Linux TCP congestion control for over a decade.
For streaming the choice of congestion control matters because video traffic is bursty and bandwidth-hungry. CUBIC works well on long fat pipes with low loss but tends to over-fill buffers on cellular links, causing bufferbloat-induced latency that masquerades as loss. BBR (Bottleneck Bandwidth and Round-trip propagation time, deployed by Google in 2016, latest variant BBRv3 in 2023) models the bottleneck capacity and target RTT directly, achieving higher throughput on lossy paths and lower latency under load. Most large CDNs offer BBR as an option, and YouTube has used it by default for years.
WebRTC has its own congestion control — Google Congestion Control (GCC) and Transport-CC — that lives above the transport layer and reacts to per-packet delay rather than loss. The choice of congestion control is invisible to viewers but tangible in operations: a CDN edge upgraded from CUBIC to BBR can sustain double the per-flow throughput on a lossy 5G uplink with no other changes.
