Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Lower-Layer (Interface, Internet and Transport) Protocols (OSI Layers 2, 3 and 4)       9  TCP/IP Transport Layer Protocols            9  Transmission Control Protocol (TCP) and User Datagram Protocol (UDP)                 9  TCP/IP Transmission Control Protocol (TCP)                      9  TCP Reliability and Flow Control Features and Protocol Modifications

TCP Window Size Adjustment and Flow Control 1 2 3 TCP "Silly Window Syndrome" and Changes To the Sliding Window System For Avoiding Small-Window Problems

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.

TCP Window Size Adjustment and Flow Control 1 2 3 TCP "Silly Window Syndrome" and Changes To the Sliding Window System For Avoiding Small-Window Problems