🤝 TCP/IP Handshake & Congestion Control

Real TCP detects loss either via a retransmission timeout (no ACK arrives within the estimated RTT plus margin) or via three duplicate ACKs (the receiver keeps ACKing the last in-order byte because a later segment arrived out of order, implying the one before it was dropped). This simulation abstracts both into a single per-RTT loss probability so you can directly see how loss frequency shapes the sawtooth, without modelling every retransmission timer.

Additive Increase, Multiplicative Decrease grows cwnd by a fixed amount each RTT when things are fine, and cuts it by a fixed fraction when loss is detected. Control theory shows AIMD converges toward fair bandwidth sharing among competing flows regardless of their starting point — an additive-increase/additive-decrease or multiplicative-increase/multiplicative-decrease scheme does not have this fairness guarantee, which is why Van Jacobson's original 1988 design chose AIMD and it has remained standard ever since.

The core AIMD shape is still there, but production stacks layer refinements on top: TCP Reno adds fast recovery so the connection doesn't fall all the way back to slow start on an isolated loss, CUBIC (Linux's default) grows cwnd as a cubic function of time since the last loss to better use high-bandwidth links, and BBR estimates the path's bottleneck bandwidth and RTT directly instead of relying on loss as the primary signal. This simulation shows the classic Tahoe/Reno-style slow-start-then-AIMD behaviour those variants all build on.

Because cwnd grows once per round trip, a connection with a 300 ms RTT takes three times as long to reach the same window size as one with a 100 ms RTT — and every RTT also gates how often "permission" to send more data is renewed. Throughput is bounded by roughly cwnd·MSS / RTT, so doubling RTT halves throughput even if cwnd eventually reaches the same ceiling.

The Mathis formula approximates steady-state TCP throughput as MSS / (RTT · √(loss rate)), capturing the idea that throughput falls with higher RTT and rises only with the square root of a falling loss rate (i.e. loss hurts more than proportionally). It's a widely used back-of-envelope estimate, but it assumes steady-state congestion avoidance only — it ignores slow start, timeouts and receive-window limits, so real measured throughput can differ substantially, especially on short-lived or bursty connections.

No — slow start always ends, either by reaching ssthresh and switching to congestion avoidance, or by hitting a loss event first, which sets a new (lower) ssthresh and restarts slow start from a small window. Because ssthresh is set adaptively from the cwnd at the moment of loss, it converges toward a value close to what the path can actually sustain.