TCP flow control

Why it exists

The receiving application reads data from TCP's receive buffer at its own speed. If the sender transmits faster than the application reads, the buffer overflows and data are dropped. Flow control lets the receiver tell the sender how much room is left. It is about protecting the receiver; protecting the network is congestion control, a separate mechanism (congestion control).

Prerequisites

You need the TCP segment, its window field and the byte numbering (TCP basics), and the sliding window idea (sliding window protocols).

Precise definitions

The receiver has a buffer of size $\text{RcvBuffer}$. Let $\text{LastByteRcvd}$ be the number of the last byte that arrived in order, and $\text{LastByteRead}$ the number of the last byte the application has taken out. The data waiting in the buffer are $\text{LastByteRcvd} - \text{LastByteRead}$, and the free space the receiver advertises in the window field of every segment it sends (including acknowledgements) is the receive window:

The sender keeps the number of bytes that are outstanding (sent, not yet acknowledged) no greater than the latest rwnd:

Hence the receive buffer cannot overflow. The window advertised is a count of bytes, counted from the acknowledgement number.

Zero window. If rwnd $= 0$ the sender stops. Since no acknowledgement will arrive to reopen the window if the receiver sends nothing more, the sender sends tiny probe segments (one byte) periodically; the reply carries the current window (quoted).

Window limit. The window field is 16 bits: $\text{rwnd} \le 65\,535$ bytes. For fast long links the window scale option (negotiated in the handshake) multiplies the field by $2^s$ (quoted).

How it works

A receiver that reads slowly

The receive buffer is $4000$ bytes and the application reads only $1000$ bytes per round trip. The sender starts with an advertised window of $4000$ bytes and sends $4000$ at once; the application reads $1000$, so the next advertised window is $1000$: the sender is slowed down to the speed of the application. In steady state each round sends $1000$ bytes, the buffer stays almost full ($3000$ to $4000$ bytes), and the transfer of $10\,000$ bytes needs $7$ rounds. The sender's average rate is the application's read rate, not the link rate: the receiver controls the speed.

Throughput limit of a window

At most one window of data can be sent per round-trip time, so

A link can be filled only if the window is at least the bandwidth-delay product (performance metrics).

With the maximum 16-bit window of $65\,535$ bytes and a round-trip time of $100$ ms the throughput cannot exceed $65535 \times 8 / 0.1 = 5.24$ Mbps, even on a $1$ Gbps link. A $1$ Gbps link with $100$ ms RTT has a bandwidth-delay product of $12.5$ MB, which needs a window about $2^8$ times larger than the field allows: that is what the window scale option provides.

Silly window syndrome (quoted)

If the receiver advertises every tiny amount of freed space (for example $1$ byte) and the sender sends a tiny segment each time, the connection exchanges $40$-byte headers for $1$ byte of data. The remedies: the receiver does not advertise a window increase until it is at least one MSS or half its buffer (Clark's solution), and the sender waits until it can send a full segment (Nagle's algorithm).

Flow control against congestion control

The sender uses the smaller of the two: $\text{LastByteSent} - \text{LastByteAcked} \le \min(\text{cwnd}, \text{rwnd})$.

Worked examples

Cheat box

Traps and GATE patterns

Connections

The advertised window is the window of the sliding window protocol, carried in TCP (sliding window protocols, TCP basics); the sender's other limit comes from congestion control. The buffer-and-reader situation is the producer-consumer problem of the operating system (classic synchronization problems).

PYQs

Assume that the bandwidth for a TCP connection is
1048560 bits/sec. Let α be the value of RTT in
milliseconds (rounded off to the nearest integer) after
which the TCP window scale option is needed. Let β
be the maximum possible window size with window
scale option. Then the values of α and β are:

Suppose two hosts use a TCP connection to transfer
a large file. Which of the following statements
is/are FALSE with respect to the TCP connection?
1. If the sequence number of a segment is m, then
the sequence number of the subsequent segment
is always m+1.
2. If the estimated round trip time at any given
point of time is t sec, the value of the
retransmission timeout is always set to greater
than or equal to t sec.
3. The size of the advertised window never
changes during the course of the TCP
connection.
4. The number of unacknowledged bytes at the
sender is always less than or equal to the
advertised window.

Self-check

Revision card

References