AIMD is a feedback model with a stated operating regime

The congestion window, often called cwnd, bounds data allowed outstanding by the sender's congestion controller. Receiver flow control, pacing, available application data, and local resources can impose tighter limits. A 100,000-byte congestion window does not promise that a router has reserved those bytes or that the receiver can accept them. When a sender has enough data and acknowledgments return steadily, bytes leaving the outstanding set allow more bytes to enter. This acknowledgment clock couples transmission opportunities to observed delivery, but compressed or delayed ACKs can make the resulting timing uneven.

A rough rate estimate divides usable outstanding bytes by RTT. It is a ceiling-like model for a window-limited steady flow, not an equality that survives arbitrary loss, startup, or receiver stalls. Increasing a window when the bottleneck is already busy may mostly add waiting bytes. RTT can then grow because the queue grows, so a higher numerator need not produce a proportional increase in delivered useful bytes per second. Compare goodput, minimum and loaded RTT, loss, and limiting state together before concluding that a larger window improved the user's transfer.

In Reno-style congestion avoidance, the window grows roughly one maximum-sized segment per RTT under suitable acknowledgment behavior. A common per-ACK approximation adds the square of the sender maximum segment size divided by the current window. The resulting change is small for each ACK but accumulates over a flight. Slow start is a different phase with more rapid, approximately exponential growth under ideal conditions. Calling slow start additive increase hides the very burst of discovery that often determines whether a short transfer ever reaches the path's available capacity.

After the classic fast-retransmit signal, the threshold is based on roughly half the outstanding flight, subject to a two-segment floor, and fast recovery temporarily adjusts the congestion window to account for presumed departures. On timer expiry, RFC 5681's congestion window falls to no more than one full-sized segment; it is not simply left at half its old value. The familiar sawtooth therefore compresses several distinct rules into a sketch. Other controllers, including CUBIC, use different growth mechanisms. Identify the controller, recovery method, and phase before applying a numerical model to a real sender.

A loss signal can result from congestion, but a sender generally lacks a perfect map from that event to a particular router and cause. Explicit Congestion Notification can convey congestion without requiring a drop when the path and endpoints support it. Wireless corruption, reordering, and receiver limitations complicate diagnosis. Even the classic intuition of competing flows converging toward equal shares has assumptions about controllers, RTTs, bottlenecks, and synchronized conditions. Equal connection counts are not automatically fair to users whose applications open different numbers of flows or need different completion-time targets.

Use independent queue-lab runs to isolate capacity pressure. Reset, explicitly set both λ=3 and μ=2, predict growth from four units at t=0, then Play or Step. Reset again, re-set both λ=1 and μ=2, and predict draining to zero at t=4 seconds before playback. Changing a control retains elapsed time and recomputes from four, not from the previously displayed backlog. These are separate constant-rate runs, without AIMD, an ACK clock, loss detection, or fairness logic. Explain which sender measurements would reconstruct an actual cwnd sawtooth instead of labeling either queue curve as one.