hesela.devTCP congestion window
The TCP congestion window is sender-maintained state that limits outstanding data according to the connection's congestion-control algorithm.
Sending constraint: In RFC 5681's model, the smaller of cwnd and the advertised receive window governs data transmission. This limit is distinct from FlightSize, the data already sent but not cumulatively acknowledged. Already outstanding bytes consume the available budget [1].
Storage boundary: A TCP byte budget is not a count of unfinished storage requests. For sustained fixed-window arithmetic, window bytes divided by RTT seconds gives a window-limited rate estimate, not a measured storage result; sender supply, loss recovery and other bottlenecks still matter [2].
RTT scope: The Mathis et al. congestion-avoidance study uses the connection's sampled RTT when queueing is present, unlike a non-congested baseline used for path budgeting. Its model assumes sufficient sender data and receiver window and excludes retransmission-timeout behavior [3].
Relations
Limitations
- RFC 5681 defines a particular congestion-control baseline, not every deployed algorithm's window evolution. [1, 2]
Citations
- RFC 5681: TCP Congestion Control, sections 2 and 3.1
- RFC 6349: Framework for TCP Throughput Testing, sections 1.2 and 3.3.1 (Informational)
- Mathis, Semke, Mahdavi and Ott: The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm (CCR 1997), sections 2, 3.1 and 3.2
Sources & caveats
- Source review, not a measured network or storage result. TCP window budgets describe one sending direction of one connection.