Flow and Congestion Control: Windows, Slow Start, and Congestion Avoidance

Two Different Limits

Reliable transfer handles loss and corruption; it does not mean a sender should accelerate indefinitely. The receiving application may read slowly, and router queues may overflow. Flow control protects the receiver; congestion control protects the network. They use receive window $rwnd$ and congestion window $cwnd$, respectively.

Flow Control and Receiver Buffers

The receiver advertises how many more bytes it can accept. With capacity $RcvBuffer$ and received but unread bytes $Buffered$, a simplified model gives:

The sender must subtract sent but unacknowledged bytes $Flight$, rather than treating the entire window as new-data credit:

This omits window scaling, window-right-edge update rules, and SACK implementation details. Application reads free buffer space, but the sender learns the new credit only after receiving a window update.

Zero Windows and Persist Probes

When the advertised window is zero, normal new-data transmission stops. If the receiver reopens the window but its update is lost, both sides could wait indefinitely. A persist timer triggers small zero-window probes so the receiver reports its window again. Probing is not permission to bulk-send beyond receiver capacity.

Congestion Windows and Feedback

When multiple senders share links, excessive in-flight data increases queuing delay and causes loss. The congestion window limits unacknowledged bytes in the network. ACKs report progress; loss or Explicit Congestion Notification (ECN) signals congestion. Wireless errors can also cause loss, so loss suggests congestion without proving it is the only cause.

Ideal window-limited throughput is approximately $\min(rwnd,cwnd)/RTT$, but link capacity, loss, and overhead impose additional limits. A large receive window does not mean the network can sustain an equally high sending rate.

Slow Start and Congestion Avoidance

This uses a simplified classic Tahoe/Reno teaching model, measuring windows in maximum segment payloads (MSS). The lab starts at $cwnd=1$ MSS and $ssthresh=8$ MSS; these are not universal modern TCP initial settings.

With enough ACKs, slow start approximately doubles the window per RTT until $ssthresh$. Congestion avoidance then adds approximately one MSS per RTT. Actual algorithms update per ACK; the lab caps an ACK round's growth at the threshold to emphasize the phase change.

Additive Increase and Multiplicative Decrease (AIMD) explores available capacity through feedback rather than knowing link bandwidth beforehand. It helps share capacity but does not guarantee strict fairness under arbitrary RTT and loss conditions.

Timeouts, Fast Retransmit, and Fast Recovery

The lesson sets the new threshold to half the pre-event window, with a minimum of two MSS. After timeout, both Tahoe and Reno reduce $cwnd$ to one MSS and restart slow start. Real threshold calculations usually use FlightSize at loss, not necessarily the current cwnd.

After three duplicate ACKs, Tahoe also restarts slow start. Classic Reno instead enters fast recovery: retransmit missing data, temporarily inflate $cwnd$ to $ssthresh+3$ MSS, then deflate to $ssthresh$ and enter congestion avoidance when new data is acknowledged. Extra duplicates, partial ACKs, and NewReno extensions are not simulated here.

Modern networks also use different congestion-control algorithms such as CUBIC. Treat this classic model as a foundation for understanding windows and feedback, not an exact reproduction of every system.