TCP Window Management Issues
(Page 2 of 3)
Reducing Buffer Size Without "Shrinking" the Window
To prevent this from occurring, TCP adds a simple rule to the basic sliding window mechanism: a device is not allowed to shrink the window. Note that there is a potential terminology ambiguity here. The words shrinking and reducing are sometimes used synonymously in colloquial discussions. As we've seen, there's nothing wrong with reducing the size of the window. The problem of shrinking the window only refers to the case where we reduce the window size so much that we contradict a prior window advertisement by taking back permission to send a certain number of bytes.
Another way of looking at this is that shrinking occurs whenever the server sends back a window size advertisement smaller than what the client considers its usable window size to be at that time. In this case, the server shrunk the window because at the time it was acknowledging the 140 bytes, it sent back a window size of 100, which is less than the 220-byte usable window the client had then.
Of course, there may well be cases where we do need to reduce a buffer, so how should this be handled? Instead of shrinking the window, the server must be more patient. In the example above where the buffer needs to be reduced to 240, the server must send back a window size of 220, freezing the right edge of the client's send window. The client can still fill the 360 byte buffer, but cannot send more than that. As soon as 120 bytes are removed from the server's receive buffer, the buffer can then be reduced in size to 240 bytes with no data loss. Then the server can resume normal operation, increasing the window size as bytes are taken from the receive buffer.
Home - Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.