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". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||^$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 Book is Here... and Now On Sale!

Searchable, convenient, complete TCP/IP information.
The TCP/IP Guide

Custom Search

Table Of Contents  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

Previous Topic/Section
TCP Window Size Adjustment and Flow Control
Previous Page
Pages in Current Topic/Section
Next Page
TCP "Silly Window Syndrome" and Changes To the Sliding Window System For Avoiding Small-Window Problems
Next Topic/Section

TCP Window Management Issues
(Page 1 of 3)

Each of the two devices on a TCP connection can adjust the window size it advertises to the other, to control the flow of data over the connection. Reducing the size of the window forces the other device to send less data; increasing the window size lets more data flow. In theory, we should be able to just let the TCP software on each of the devices change the window size as needed to match the speed at which data both enters the buffer and is removed from it to be sent to the receiving application.

Problems Associated With "Shrinking" The TCP Window

Unfortunately, certain changes in window size can lead to undesirable consequences. These can occur both when the size of the window is reduced and when it is increased. For this reason, there are a few issues related to window size management that we need to consider. As in previous topics, we'll use for illustration a modification of the same client/server example first shown in the topic explaining the basic TCP data transfer process.

One window size management matter is related to just how quickly a device reduces the size of its receive window when it gets busy. Let's say the server starts with a 360 byte receive window, as in the aforementioned example, and receives 140 bytes of data that it acknowledges, but cannot remove from the buffer immediately. The server can respond by reducing the size of the window it advertises back to the client. We even discussed in the previous topic the case where no bytes can be removed from the buffer at all, so the window size is reduced by the same 140 bytes that were added to the buffer. This “freezes” the right edge of the client's send window so it cannot send any additional data when it gets an acknowledgment.

What if the server were so overloaded that we actually needed to reduce the size of the buffer itself? Say memory was short and the operating system said “I know you have 360 bytes allocated for the receive buffer for this connection, but I need to free up memory so now you only have 240”. The server still can't immediately process the 140 bytes it received, so it would need to drop the window size it sent back to the client all the way from 360 bytes down to 100 (240 in the total buffer less the 140 already received).

In effect, doing this actually moves the right edge of the client's send window back to the left. It says “not only can't you send more data when you receive this acknowledgment, but you now can send less”. In TCP parlance, this is called shrinking the window.

There's a very serious problem with doing this, however: while the original 140 bytes were in transit from the client to the server, the client still thought it had 360 bytes of total window, of which 220 bytes were usable (360 less 140). The client may well have already sent some of that 220 bytes of data to the server before it gets notification that the server has shrunk the window! If so, and the server reduces its buffer to 240 bytes with 140 used, when those 220 bytes show up at the server, only 100 will fit and any additional ones will need to be discarded. This will force the client to have to retransmit that data, which is inefficient. Figure 227 illustrates graphically how this situation would play out.

Figure 227: The Problem With “Shrinking” The TCP Window

In this modification of the example of Figure 226, the client begins with a usable window size of 360. It sends a 140-byte segment and then a short time thereafter sends one of 180 bytes. The server is busy, however, and when it receives the first transmission decides to reduce its buffer to 240 bytes. It holds the 140 bytes just received and reduces its receive window all the way down to 100. When the client’s 180-byte segment arrives, there is only room for 100 of the 180 bytes in the server’s buffer. When the client gets the new window size advertisement of 100, it will have a problem because it already has 180 bytes sent but not acknowledged.


Previous Topic/Section
TCP Window Size Adjustment and Flow Control
Previous Page
Pages in Current Topic/Section
Next Page
TCP "Silly Window Syndrome" and Changes To the Sliding Window System For Avoiding Small-Window Problems
Next Topic/Section

If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $

Home - Table Of Contents - Contact Us

The TCP/IP Guide (
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.