TCP CUBIC
/ CUBIC: KEW-bik /
Classic TCP grows its window by one packet per round trip after a loss. On a slow local link that is fine, but on a very fast, long-distance link — a gigabit pipe to another continent — refilling the window one packet at a time after each loss can take literally minutes, leaving most of the bandwidth idle. CUBIC is a redesign of the climb that fixes this, and it has been the default congestion controller in Linux (and therefore on a huge fraction of the world's servers) for many years.
The key idea is in the name: after a loss, CUBIC grows the congestion window along a cubic curve in time, rather than a straight line. Right after the cut, it climbs fast to get back near the window size where the loss happened (called the plateau, or W_max). As it approaches that remembered ceiling it slows down and probes cautiously — the flat middle of the cubic curve — and if no loss occurs there, it accelerates again beyond it to discover newly available capacity. Cleverly, this growth is a function of real time since the last loss, not of the number of round trips, which makes CUBIC behave more fairly between flows with very different RTTs than classic AIMD does.
CUBIC is still fundamentally loss-based: like Reno, it treats a dropped packet as the signal to back off, and it inherits the same blind spot — it cannot tell congestion loss from random wireless loss, and it tends to keep router buffers full (contributing to bufferbloat) because it only retreats once a buffer overflows. But for the common case of high-speed wired links it is far more efficient than the old linear climb, which is why it quietly carries an enormous share of Internet traffic today.
On a 10 Gbps transcontinental link, classic Reno after a loss might add one 1500-byte packet per 150 ms RTT — crawling back to full speed over many minutes. CUBIC instead races back toward the previous window with its cubic curve, levels off to probe gently around the old ceiling, then pushes past it, recovering full throughput in seconds rather than minutes.
CUBIC's time-based cubic climb refills a fast, long path far quicker than Reno's one-packet-per-RTT line.
CUBIC is more efficient than Reno but shares Reno's core weaknesses: it is loss-based, so it still mistakes wireless error loss for congestion, and it tends to fill buffers before backing off, worsening bufferbloat and latency. BBR was created partly to escape these loss-based limitations by modelling the path instead.