Introduction

Every time your browser fetches a page, your operating system is quietly negotiating how fast it can push data. Too fast and packets pile up, routers drop them, and the whole network chokes. Too slow and you waste capacity you paid for. The algorithm in the middle is TCP congestion control.

The classic answer, TCP Reno (early 1990s), uses additive increase, multiplicative decrease (AIMD): grow the congestion window WW by one segment per round-trip time (RTT), and halve it on loss. That linear ramp works fine on a dial-up modem, but on a modern 10 Gbps link with 50 ms of latency, you need tens of thousands of in-flight packets just to fill the pipe — and AIMD spends enormous time crawling back up after every loss.

TCP CUBIC (Sangtae Ha, Injong Rhee, and Lisong Xu, 2008; Linux default since kernel 2.6.19 in 2006) replaces that linear ramp with a cubic polynomial. After a loss event, the window grows as a function of elapsed time since the last loss, not of RTTs:

W(t)=C (t−K)3+Wmax⁡W(t) = C\,(t - K)^{3} + W_{\max}

where Wmax⁡W_{\max} is the window at the last loss, CC is a scaling constant, KK is chosen so that W(0)=Wmax⁡/2W(0) = W_{\max}/2 (the window right after loss), and tt is the time elapsed since that loss. The cubic shape means growth is fast far from Wmax⁡W_{\max} and gentle near it — exactly where you want to probe carefully to avoid triggering another loss.

Crucially, the formula uses wall-clock time, not RTT count. A connection with a 5 ms RTT and one with a 200 ms RTT both grow at the same wall-clock rate — making CUBIC RTT-fair across very different paths.

CUBIC vs Reno

The simulation below runs both algorithms in parallel from the same loss event and shows how their congestion windows (WW) evolve over time. Press Simulate loss to trigger a loss event and watch them recover; press Reset to start fresh.

<!-- TCP CUBIC vs Reno congestion-window simulation -->
<div class="controls">
  <label class="ctrl-label">RTT: <input id="rtt" type="range" min="10" max="200" value="50" step="10"> <span id="rtt-val">50 ms</span></label>
  <label class="ctrl-label">Bandwidth: <input id="bw" type="range" min="10" max="200" value="100" step="10"> <span id="bw-val">100 Mbps</span></label>
</div>
<canvas id="chart" width="560" height="260"></canvas>
<div class="legend">
  <span class="dot cubic"></span> CUBIC
  <span class="dot reno"></span> Reno
</div>
<div class="status" id="status">Press "Simulate loss" to start both algorithms and trigger a loss event.</div>
<div class="btns">
  <button id="btn-loss" type="button">Simulate loss</button>
  <button id="btn-reset" type="button" class="ghost">Reset</button>
</div>

/* Styles for the CUBIC vs Reno congestion window chart */
* { box-sizing: border-box; }
body { font-family: system-ui, sans-serif; color: #222; margin: 0; }
.controls { display: flex; flex-wrap: wrap; gap: .6rem 1.2rem; margin-bottom: .6rem; font-size: .85rem; }
.ctrl-label { display: flex; align-items: center; gap: .4rem; }
input[type=range] { width: 100px; accent-color: #1d3557; }
canvas { display: block; border: 1px solid #cdd9e3; border-radius: 8px; background: #f8fafb; max-width: 100%; }
.legend { font-size: .82rem; margin: .4rem 0; display: flex; gap: 1rem; align-items: center; }
.dot { display: inline-block; width: 12px; height: 12px; border-radius: 50%; }
.dot.cubic { background: #1d6fa5; }
.dot.reno  { background: #e06c00; }
.status { font-size: .95rem; font-weight: 600; min-height: 1.4em; margin: .3rem 0; }
.btns { display: flex; gap: .5rem; flex-wrap: wrap; }
button { font: 600 14px system-ui, sans-serif; padding: .45rem .9rem; border: 1px solid #1d3557;
         background: #1d3557; color: #fff; border-radius: 8px; cursor: pointer; }
button.ghost { background: #fff; color: #1d3557; }

/* TCP CUBIC vs Reno side-by-side simulation */
const i18nFmt = (s, v) => s.replace(/%(\w+)%/g, (_, k) => String(v[k] ?? ''));

/* Simulation constants */
const C_CUBIC = 0.4;   // CUBIC scaling constant (Linux default 0.4)
const BETA = 0.3;       // multiplicative decrease factor
const MSS = 1500;       // maximum segment size in bytes
const SIM_SEC = 8;      // total simulation length in seconds
const STEP = 0.04;      // time step per animation frame in seconds

let rttMs = 50;
let bwMbps = 100;
let cubicData = [];
let renoData = [];
let lossTime = null;    // wall-clock second when loss event was triggered
let running = false;
let animId = null;
let tSim = 0;

const canvas = document.getElementById('chart');
const ctx = canvas.getContext('2d');
const statusEl = document.getElementById('status');

function setStatus(msg) { statusEl.textContent = msg; }

/* CUBIC window at elapsed time t since loss, given wMax at loss */
function cubicWindow(t, wMax) {
  const K = Math.cbrt((wMax * BETA) / C_CUBIC);
  return C_CUBIC * Math.pow(t - K, 3) + wMax;
}

/* Reno window grows linearly at 1 segment per RTT */
function renoWindow(t, wMax, rtt) {
  return (wMax / 2) + (t / rtt);
}

function maxSegs() {
  /* target max window = 2x the bandwidth-delay product in segments */
  return Math.max(200, Math.round((bwMbps * 1e6 / 8 * rttMs / 1000) / MSS) * 2);
}

function draw() {
  const W = canvas.width;
  const H = canvas.height;
  ctx.clearRect(0, 0, W, H);

  const pad = { top: 20, right: 20, bottom: 36, left: 56 };
  const pw = W - pad.left - pad.right;
  const ph = H - pad.top - pad.bottom;
  const maxW = maxSegs();

  /* draw chart axes */
  ctx.strokeStyle = '#cdd9e3';
  ctx.lineWidth = 1;
  ctx.beginPath();
  ctx.moveTo(pad.left, pad.top);
  ctx.lineTo(pad.left, pad.top + ph);
  ctx.lineTo(pad.left + pw, pad.top + ph);
  ctx.stroke();

  /* draw tick marks and labels */
  ctx.fillStyle = '#888';
  ctx.font = '11px system-ui';
  ctx.textAlign = 'right';
  for (let segs of [0, Math.round(maxW * 0.25), Math.round(maxW * 0.5), Math.round(maxW * 0.75), maxW]) {
    const y = pad.top + ph - (segs / maxW) * ph;
    ctx.beginPath(); ctx.moveTo(pad.left - 4, y); ctx.lineTo(pad.left, y); ctx.stroke();
    ctx.fillText(segs, pad.left - 7, y + 4);
  }
  ctx.textAlign = 'center';
  for (let s = 0; s <= SIM_SEC; s += 2) {
    const x = pad.left + (s / SIM_SEC) * pw;
    ctx.beginPath(); ctx.moveTo(x, pad.top + ph); ctx.lineTo(x, pad.top + ph + 4); ctx.stroke();
    ctx.fillText(s + 's', x, pad.top + ph + 15);
  }

  /* axis labels */
  ctx.save();
  ctx.translate(14, pad.top + ph / 2);
  ctx.rotate(-Math.PI / 2);
  ctx.textAlign = 'center';
  ctx.fillText('Window (segments)', 0, 0);
  ctx.restore();
  ctx.textAlign = 'center';
  ctx.fillText('Time (seconds)', pad.left + pw / 2, H - 4);

  /* draw vertical line at the loss event */
  if (lossTime !== null) {
    const lx = pad.left + (lossTime / SIM_SEC) * pw;
    ctx.strokeStyle = '#c0392b';
    ctx.lineWidth = 1.5;
    ctx.setLineDash([4, 4]);
    ctx.beginPath();
    ctx.moveTo(lx, pad.top);
    ctx.lineTo(lx, pad.top + ph);
    ctx.stroke();
    ctx.setLineDash([]);
    ctx.fillStyle = '#c0392b';
    ctx.textAlign = 'left';
    ctx.font = '10px system-ui';
    ctx.fillText('loss', lx + 3, pad.top + 12);
  }

  /* draw one data series as a polyline */
  function drawSeries(data, color) {
    if (data.length < 2) return;
    ctx.strokeStyle = color;
    ctx.lineWidth = 2;
    ctx.beginPath();
    data.forEach(([t, w], i) => {
      const x = pad.left + (t / SIM_SEC) * pw;
      const y = pad.top + ph - Math.min(w, maxW) / maxW * ph;
      i === 0 ? ctx.moveTo(x, y) : ctx.lineTo(x, y);
    });
    ctx.stroke();
  }

  drawSeries(cubicData, '#1d6fa5');
  drawSeries(renoData, '#e06c00');
}

function simulate() {
  /* advance simulation by one step */
  if (lossTime === null) {
    /* before a loss event, both algorithms hold steady at 80% wMax */
    const wNow = maxSegs() * 0.8;
    cubicData.push([tSim, wNow]);
    renoData.push([tSim, wNow]);
    draw();
    tSim += STEP;
    if (tSim < SIM_SEC) animId = requestAnimationFrame(simulate);
    else { running = false; setStatus('Simulation complete.'); }
    return;
  }

  const elapsed = tSim - lossTime;
  const wMax = maxSegs() * 0.8;  // window at the moment of loss; fixed so both algorithms start equal

  const wCubic = Math.max(1, cubicWindow(elapsed, wMax));
  const rttSec = rttMs / 1000;
  const wReno = Math.max(1, renoWindow(elapsed, wMax, rttSec));

  cubicData.push([tSim, wCubic]);
  renoData.push([tSim, wReno]);
  draw();

  tSim += STEP;
  if (tSim < SIM_SEC) {
    animId = requestAnimationFrame(simulate);
  } else {
    running = false;
    setStatus(i18nFmt('Final window — CUBIC: %cubic% segs, Reno: %reno% segs.', {
      cubic: Math.round(wCubic),
      reno: Math.round(wReno)
    }));
  }
}

function triggerLoss() {
  if (lossTime !== null) return;
  lossTime = tSim;
  setStatus('Loss triggered! Watch CUBIC recover faster than Reno.');
}

function reset() {
  if (animId) cancelAnimationFrame(animId);
  running = false;
  lossTime = null;
  tSim = 0;
  cubicData = [];
  renoData = [];
  setStatus('Press "Simulate loss" to start both algorithms and trigger a loss event.');
  draw();
}

document.getElementById('rtt').addEventListener('input', function() {
  rttMs = +this.value;
  document.getElementById('rtt-val').textContent = rttMs + ' ms';
});
document.getElementById('bw').addEventListener('input', function() {
  bwMbps = +this.value;
  document.getElementById('bw-val').textContent = bwMbps + ' Mbps';
});

document.getElementById('btn-loss').addEventListener('click', function() {
  if (!running) {
    running = true;
    setStatus('Running — press "Simulate loss" again to trigger loss now.');
    simulate();
    setTimeout(triggerLoss, 2000);
  } else {
    triggerLoss();
  }
});
document.getElementById('btn-reset').addEventListener('click', reset);

draw();
Result
Console

Notice that Reno climbs at a constant one-segment-per-RTT slope, while CUBIC rockets past and then flattens as it approaches the old maximum — probing carefully right where another loss is most likely. On high-bandwidth, high-latency paths the difference in throughput can be dramatic.

The Real Complexity

CUBIC's elegance hides several careful design decisions.

The cubic window function. The parameter KK is derived at each loss event so that the window recovers exactly to Wmax⁡W_{\max} at time t=Kt = K:

K=Wmax⁡⋅βC3K = \sqrt[3]{\frac{W_{\max} \cdot \beta}{C}}

where β=0.3\beta = 0.3 is the multiplicative decrease factor and C=0.4C = 0.4 is the cubic scaling constant (Linux defaults). Far below Wmax⁡W_{\max}, the cubic term is large and growth is steep. Near Wmax⁡W_{\max}, the derivative 3C(t−K)23C(t-K)^{2} is small — CUBIC slows down precisely where it needs to probe gently.

RTT-independence. Classic AIMD grows by one segment per RTT, so a 200 ms connection grows four times slower than a 50 ms one. CUBIC's time-based growth means every connection races up the same cubic curve at the same wall-clock speed. Long-distance flows are no longer penalized.

TCP-friendliness mode. When RTTs are short and the network is lightly loaded, pure cubic growth can be slower than Reno's linear ramp. CUBIC detects this case by comparing its window to the Reno estimate West(t)=Wmax⁡/2+3 β/(3−β)⋅t/RTTW_{\text{est}}(t) = W_{\max}/2 + 3\,\beta/(3-\beta) \cdot t/RTT and falls back to the faster one. This ensures CUBIC never under-uses a path that Reno could fill.

Bandwidth-delay product (BDP) awareness. The real bottleneck on a fat-and-long pipe is the bandwidth-delay product — the number of bits in flight at full speed. For a 10 Gbps link with 100 ms RTT, BDP ≈125\approx 125 MB, or roughly 90,000 segments. AIMD can take hundreds of seconds to climb there; CUBIC reaches it in seconds.

The algorithm is described in RFC 9438 (a playful cross-link; the actual RFC is at the footer) and studied in the same body of work as network flow algorithms that model how data moves through constrained pipes.

Where It Matters

TCP CUBIC is not an academic curiosity — it is the default congestion-control algorithm on every modern Linux kernel, which means it runs on:

  • Android phones: every TCP connection your phone makes uses CUBIC.
  • Cloud providers: AWS, Google Cloud, and Azure all run Linux host stacks with CUBIC (or derivatives like BBR that build on the same RTT-independence insight).
  • Content delivery: streaming video from Netflix, YouTube, and similar platforms relies on CUBIC to rapidly saturate high-bandwidth paths between CDN nodes.
  • Data centers: east-west traffic between servers shares the same algorithm, balancing thousands of concurrent flows.
  • Home broadband: your router's TCP stack (if it runs Linux — and most do) uses CUBIC for every upload.

CUBIC's successor in high-stakes deployments is often BBR (Bottleneck Bandwidth and RTT), which goes further by modeling the pipe directly rather than reacting to loss. But BBR is more complex and can be aggressive toward other flows; CUBIC remains the safer, well-understood default. Understanding CUBIC's cubic growth is also a clean entry point into broader ideas like scheduling and resource allocation under constraints.

Conclusion

TCP CUBIC's insight is deceptively simple: measure elapsed time after a loss, not elapsed round trips, and let the window grow as a cubic — fast at first, cautious near the danger zone. That single change freed long-distance connections from the RTT penalty that crippled AIMD on fat-and-long pipes.

The algorithm is solved and deployed: CUBIC has been the Linux default since 2006, standardized in RFC 9438, and its ideas — RTT-independence, careful probing near the previous maximum — have influenced every major congestion-control proposal since. The next time your download saturates a gigabit link, a cubic function is the quiet reason why.

Share this article

Pick a channel — or use your device's native share sheet.

Comments

Loading comments...

https://www.kipuhub.com/en/article/tcp-cubic/Content licensed under CC BY-NC 4.0.