When TCP sender window shrinks?

Question

I was learning TCP from Forouzan's book. It explains sender side window as follows:

In that it defines size of receiver window as follows:

rwnd = receiver buffer size - number of bytes waiting to be consumed by receiver process

It then says:

• Sender side window closes (moves left wall of windows to right), when it receives some acknowledgements
• sender side window opens (moves right wall to right), when receiver communicates rnwd such that
  new ackNo + new rwnd > old ackNo + last rwnd
• The send window shrinks (moves right window to right) in the event above situation does not occur.

It shows opening and closing of sender window as follows:

It does not show shrinking of window. I dont get why shrinking will ever occur. If you look at formula for rwnd in first quoted text above, shrinking will require reduction of receiver buffer size, correct? If yes does that happen (I feel this buffer size must be fixed)? And if yes why? Due to reduction of free RAM of the computer running TCP receiver?

Answer 1

The receive buffer could be a fixed size, and that really plays no part in the receive window, except to place an absolute maximum on the receive window size. The real definition of a receive window is to be found in RFC 793, Transmission Control Protocol, which is the definition of TCP. The receive window is explained in several places in the RFC. For example:

Flow Control:

TCP provides a means for the receiver to govern the amount of data sent by the sender. This is achieved by returning a "window" with every ACK indicating a range of acceptable sequence numbers beyond the last segment successfully received. The window indicates an allowed number of octets that the sender may transmit before receiving further permission.

Assume that the receiver has a fixed buffer size of 10,000 bytes and starts with a receive window of that size. If it has received 4,000 bytes, but the application process has not yet consumed those bytes from the receive buffer, TCP will acknowledge the received bytes, but specify the receive window is now 6,000 bytes because that is all that is left in the buffer. The receiver is telling the sender that it should stop sending more data after it sends 6,000 more bytes, unless the receiver gives it a different receive window size. Remember, TCP is a process that is not the application process, and TCP will maintain the connection and the receive window based on its available resources, which are filled until the application process gets around to consuming the data and freeing TCP resources.

It does not show shrinking of window.

The diagram seems to show the send window shrinking and expanding (800 to 600 to 400, and back to 600 on the client). It also shows the receive window (on the server) shrinking as data are received, until the application process consumes some data from TCP, at which point the receive window grows by the amount consumed.

---

TCP doesn't have clients or servers, it creates connections between two peers, so I'm not sure why the book implies that; it only serves to confuse things. In this case, the client is the sender, and the server is the receiver, and that is backwards from what many people use. Either TCP peer can both send and receive (each is a sender and a receiver). The RFC for TCP doesn't mention clients or servers.