Flow Control and Window Management
Every TCP segment (except those exchanged during connection establishment) includes a valid Sequence Number field, an ACK Number or Acknowledgment field, and a Window Size field (containing the window advertisement).
These sizes(contained in window advertisement field) represent the amount of space the sender of the segment has reserved for storing incoming data the peer sends.
When TCP-based applications are not busy doing other things, they are typically able to consume any and all data TCP has received and queued for them, leading to no change of the Window Size field as the connection progresses.
On slow systems, or when the application has other things to accomplish, data may have arrived for the application, been acknowledged by TCP, and be sitting in a queue waiting for the application to read or “consume” it.
When TCP starts to queue data in this way, the amount of space available to hold new incoming data decreases, and this change is reflected by a decreasing value of the Window Size field.
Eventually, if the application does not read or otherwise consume the data at all, TCP must take some action to cause the sender to cease sending new data entirely,
because there would be no place to put it on arrival. This is accomplished by sending a window advertisement of zero (no space).
The largest sequence number the sender of a segment is willing to accept in the reverse direction is equal to the sum of the Acknowledgment Number and Window Size fields in the TCP header (scaled appropriately).
Sliding Windows
The amount of data sent or received on a connection is maintained by a set of window structures.
For each active connection, each TCP endpoint maintains a send window structure and a receive window structure.
TCP maintains its window structures in terms of bytes (not packets).In Fig- ure 15-9 we have numbered the bytes 2 through 11.
The window advertised by the receiver is called the offered window and covers bytes 4 through 9,
meaning that the receiver has acknowledged all bytes up through and including number 3 and has advertised a window size of 6.
The sender computes its usable window, which is how much data it can send immediately.
The usable window is the offered window minus the amount of data already sent but not yet acknowledged.
The vari- ables SND.UNA and SND.WND are used to hold the values of the left window edge and offered window.
The variable SND.NXT holds the next sequence number to be sent, so the usable window is equal to (SND.UNA + SND.WND – SND.NXT).
Over time this sliding window moves to the right, as the receiver acknowl- edges data.
The relative motion of the two ends of the window increases or decreases the size of the window.
Three terms are used to describe the movement of the right and left edges of the window
1 The window closes as the left edge advances to the right.
This happens when data that has been sent is acknowledged and the window size gets smaller.
2 The window opens when the right edge moves to the right, allowing more data to be sent.
This happens when the receiving process on the other end reads acknowledged data, freeing up space in its TCP receive buffer.
3 The window shrinks when the right edge moves to the left.
The Host Requirements RFC [RFC1122] strongly discourages this, but TCP must be able to cope with it.
The left edge of the window cannot move to the left, because this edge is controlled by the ACK number received from the other end that is cumulative and never goes backward.
When the ACK number advances the window but the window size does not change (a common case), the window is said to advance or “slide” forward.
If the ACK number advances but the window advertisement grows smaller with other arriving ACKs, the left edge of the window moves closer to the right edge.
If the left edge reaches the right edge, it is called a zero window. This stops the sender from transmitting any data.
If this happens, the sending TCP begins to probe the peer’s window (see Section 15.5.2) to look for an increase in the offered window.
The receiver also keeps a window structure, which is somewhat simpler than the sender’s.
The receiver window structure keeps track of what data has already been received and ACKed, as well as the maximum sequence number it is willing to receive.
The TCP receiver depends on this structure to ensure the correctness of the data it receives.
In particular, it wishes to avoid storing duplicate bytes it has already received and ACKed, and it also wishes to avoid storing bytes that it should not have received
(any bytes beyond the sender’s right window edge).
Zero Windows and the TCP Persist Timer
When the receiver once again has space available, it provides a window update to the sender to indicate that data is permitted to flow once again.
Because such updates do not generally contain data (they are a form of “pure ACK”), they are not reliably delivered by TCP.
TCP must therefore handle the case where such window updates that would open the window are lost.
If an acknowledgment (containing a window update) is lost, we could end up with both sides waiting for the other: the receiver waiting to receive data
(because it provided the sender with a nonzero window and expects to see incoming data) and the sender waiting to receive the window update allowing it to send.
To pre- vent this form of deadlock from occurring, the sender uses a persist timer to query the receiver periodically, to find out if the window size has increased.
The persist timer triggers the transmission of window probes.
Window probes are segments that force the receiver to provide an ACK, which also necessarily contains a Win- dow Size field.
The Host Requirements RFC [RFC1122] suggests that the first probe should happen after one RTO and subsequent problems should occur at exponen- tially spaced intervals
(i.e., similar to the “second part” of Karn’s algorithm, which we discussed in Chapter 14).
Window probes contain a single byte of data and are therefore reliably deliv- ered (retransmitted) by TCP if lost, thereby eliminating the potential deadlock condition caused by lost window updates.
The probes are sent whenever the TCP persist timer expires, and the byte included may or may not be accepted by the receiver, depending on how much buffer space it has available.
As with the TCP retransmission timer (see Chapter 14), the normal exponential backoff can be used when calculating the timeout for the persist timer.
An important difference, how- ever, is that a normal TCP never gives up sending window probes, whereas it may eventually give up trying to perform retransmissions.
This can lead to a certain resource exhaustion vulnerability that we discuss in Section 15.7.