Toolgeist › Developer

TCP Congestion Control Simulator — Tahoe vs Reno vs NewReno vs CUBIC

Four congestion control algorithms, each implemented from its actual specification, racing on the same bottleneck link. Tahoe collapses its window to 1 on any loss; Reno halves it via fast recovery but still collapses on a retransmission timeout; NewReno takes one reduction per window instead of one per lost packet; and CUBIC follows the RFC 8312 growth function W(t) = C(t−K)³ + W_max with β = 0.7 and C = 0.4, including the TCP-friendly region and fast convergence. Switch to the transatlantic link and the reason CUBIC replaced Reno as the Linux default stops being an abstract claim and becomes a number you can read off the chart.

How to use TCP Congestion Control Simulator — Reno vs CUBIC

  1. Pick two or more algorithms to compare.
  2. Choose a link — home broadband, transatlantic fibre, mobile, or datacenter.
  3. Watch the sawtooth: dots are loss events, the dashed line is the bandwidth-delay product.
  4. Raise "drops per loss event" to 4 and compare Reno against NewReno.

Frequently asked questions

Why does CUBIC beat Reno on long-distance links?
Reno adds exactly one packet per round trip after a loss. On a 350-packet pipe with a 90 ms RTT that is hundreds of round trips — tens of seconds — to get back to full speed. CUBIC’s cubic function grows slowly near the previous maximum but aggressively far below it, so it reclaims the pipe in a fraction of the time. Compare the "packets delivered" figures on the transatlantic preset.
What actually separates Reno from NewReno?
Behaviour when several packets drop in the same window. Classic Reno reduces once per lost packet, so a burst loss can halve the window three or four times over. NewReno stays in fast recovery until the whole window is acknowledged and reduces once. Set drops per loss event to 4 on the mobile link to see the gap.
Why do some loss events trigger a timeout instead of fast retransmit?
Fast retransmit needs three duplicate ACKs, which requires at least four packets in flight. When the window is already tiny there are not enough packets to generate them, so the sender has to wait for a retransmission timeout — far more expensive. This is modelled here, which is why the lossy mobile preset shows RTO counts that the wide links do not.
What is the dashed line above the capacity line?
The bandwidth-delay product: the window size that exactly fills the link. Anything above it is sitting in the router’s buffer, adding latency without adding throughput. That gap between BDP and drop point is bufferbloat, and it is why modern algorithms like BBR try to sit at the BDP rather than probing until packets drop.
Is this a packet-level simulator like ns-3?
No, and it does not claim to be. It is a per-RTT-round model: each round the sender transmits cwnd packets and the drop-tail bottleneck drops whatever exceeds its capacity. The window update arithmetic for each algorithm is the real specified arithmetic, but there is no per-packet queueing, reordering or ACK clocking.

Related Developer tools

Also searched for: tcp reno vs cubic · congestion window sawtooth explained · why is cubic the linux default · tcp slow start vs congestion avoidance · bandwidth delay product bufferbloat

Browse all 738 free tools on Toolgeist →