Explain how TCP provide a flow control service by using different variables.

How the receive window enforces flow control

The TCP header includes a window field that carries the receiver’s current receive window. This tells the sender the maximum amount of data (in bytes) that the receiver can accept beyond what has already been acknowledged. 2

Usable window at the sender

At any moment, the sender can conceptually compute a bound of the form:

$$\text{in-flight bytes} \le \text{rwnd}$$

Where:

• “in-flight bytes” is the amount of data sent but not yet acknowledged (a function of sequence numbers and ACK state).
• “rwnd” is the receiver’s advertised capacity.

So the sender uses:

• the receiver’s cumulative ACK to determine what is already safely received,
• plus the receiver’s advertised window to determine what additional bytes may be sent without overflowing the receiver buffer. 2

Sliding-window consequence. As the receiver consumes data from its buffer, it increases the advertised rwnd; as it fills, it decreases it. This continually “slides” the permissible sending region forward without requiring per-packet coordination.

Footnotes

1. (RFC 793) Transmission Control Protocol (https://www.rfc-editor.org/rfc/rfc793) - Defines TCP’s acknowledgment, window, and sliding-window behavior in terms of send/receive sequence space and the advertised window. ↩ ↩² ↩³

2. TCP flow control and zero-window behavior explanation (https://www.rfc-editor.org/rfc/rfc1122) - Contains host requirements including how windowing and acknowledgment/window update behavior should function, including handling of zero windows. ↩ ↩²

Differentiating flow control variables from congestion control variables

TCP has two related but distinct control services:

1. Flow control protects the receiver’s buffer capacity (receiver-advertised window: rwnd).
2. Congestion control protects the network path capacity (sender-side congestion window, cwnd).

The sender therefore typically limits sending by the combination of:

• rwnd (flow control)
• cwnd (congestion control)

Conceptually:

$$\text{effective\_send\_window} = \min(\text{cwnd}, \text{rwnd})$$

This means that even if the receiver advertises large rwnd, the sender may still be limited by cwnd when congestion control reduces it; conversely, even if cwnd is large, a small rwnd will throttle the sender to prevent receiver overflow.

Footnotes

1. (TCP Congestion Control overview) RFC 5681 TCP Congestion Control (https://www.rfc-editor.org/rfc/rfc5681) - Separates congestion control concepts (cwnd) from receiver-side flow control via advertised windows. ↩

Zero-window and window reopening (why “rwnd=0” matters)

A receiver may advertise rwnd as 0 when its receive buffer is full. The sender then cannot legally send additional bytes beyond the already acknowledged data. When the receiver drains enough buffer space, it sends an updated ACK with a non-zero window to reopen the flow-controlled sending ability. This handshake pattern ensures correctness and protects receiver capacity.

Footnotes

1. TCP flow control and zero-window behavior explanation (https://www.rfc-editor.org/rfc/rfc1122) - Contains host requirements including how windowing and acknowledgment/window update behavior should function, including handling of zero windows. ↩

Variables summary table (what each represents)