Skip to content

CONCEPT Cited by 1 source

CUBIC congestion control

Definition

CUBIC is a TCP congestion-control algorithm introduced in 2008 and standardised in RFC 8312 (2018). It has been the default congestion controller in the Linux kernel since Linux 2.6.19 (2006) and is the dominant algorithm for broad internet traffic today.

CUBIC is a window-based, loss-signalled controller: it grows the congestion window as a cubic function of time since the last loss event, aggressively probing for bandwidth while avoiding the slow linear growth of older schemes like NewReno.

Canonical framing on the wiki

Zalando's 2024-06 post names CUBIC as the dominant-in-practice algorithm — contrasting with the QUIC specification's choice of NewReno as default:

"Nowadays, NewReno (1999), CUBIC (2008) and Bottleneck Bandwidth and Round-trip (2016) are the heuristic congestion control algorithms. QUIC standard is confusing, it proposes NewReno as default algorithm, although CUBIC is the dominant algorithm for the broad internet traffic today." (Source: sources/2024-06-17-zalando-next-level-customer-experience-with-http3-traffic-engineering)

5G radio-access limitations

On 5G mid-bands, Zalando's post cites a 2021 MDPI paper showing CUBIC + NewReno produce "very poor throughput and latency performance" under 5G physical-failure scenarios — noise, interference, blockages, handover. The reason: these loss-signalled algorithms treat any packet loss as a congestion signal, but on radio channels most loss is not congestion, it's RF. Only BBR exhibits low RTT across the failure matrix in the same study.

Why it dominated

  • Loss-signalled and self-clocked — works without network cooperation; backward compatible with NewReno ecosystem.
  • Cubic growth curve — more aggressive than NewReno's AIMD (additive-increase-multiplicative-decrease), especially on high-BDP paths (long-fat networks), while still backing off on loss.
  • Kernel default — shipping as the Linux default meant CUBIC ran on the majority of internet servers without explicit choice.

Contrasts

  • vs. NewReno — more aggressive on bandwidth probing; more TCP-friendly on short RTTs.
  • vs. BBR — loss-signalled (not model-based), so mis-identifies RF loss on radio channels as congestion; BBR uses bottleneck-bandwidth + RTT estimation instead.
  • vs. Deep-RL CC (Aurora, Eagle, Orca, PQB) — heuristic, not learned; inherits the limits of fixed decision rules.

Seen in

Last updated · 501 distilled / 1,218 read