I am trying to troubleshoot speed issues for a customer connecting to a Web Site from abroad. We have carried out testing by asking carrying out downloads of files from our Web site & capturing traffic during this.
We can see that once the download commences, after a short amount of packets, the TCP Window size on the receiving host drops to zero. After a short while this resumes & then does not drop below 40000.
On this machine the Windows Scaling option is set to 3 & the TCP Window size set to 65535. Even with the scaling option set the TCP Window size never goes above 65535 in the packets (which I am told is normal).
I am surprised that, with the scaling set to 3, the TCP Window size still reduces to zero.
IS this normal behaviour? I am guessing that the TCP Window reducing to zero is because of some resource limitation on the Receiving host...?
Any assistance would be greatly appreciated. Thanks Ian
asked 16 Feb '11, 05:07
TCP window dropping to Zero means that the receiving host has trouble processing incoming data fast enough. Even with window scaling it is something that can happen - the larger the window the longer it takes to drop to zero. If the receiving station is too slow to process data and it has to receive more data than the window size is in size it will go down to zero.
You can take a look at the "bytes in flight" value in the sender's tcp header to see how much data has not yet been acknowledged - it ususally shows pretty high numbers if the receiver is too slow to process the incoming flood of packets.
Zero windows very often indicate an overloaded receiving station (either OS or slow application), and is a good indicator that "it is NOT the network" :-)
Exception are Reset-Packet - they usually have a window size of 0 and are not an indication of an overworked station.
answered 16 Feb '11, 05:31
edited 16 Feb '11, 05:32
When you look at that station communicating - how do you know the Window Scale is in use?
Do you see a "scaled" value in the host's TCP headers?
Here's the deal and it's all over the place these days. - your client can be set to use Window Scaling (TCP options in handshake) - if the server doesn't support it, neither side will use it (look at server handshake response) - if an intermediary device (such as a "smart firewall" - ugh) doesn't like/support that option for the path, it might strip off your client's TCP option (thinking Cisco ASA here). - if Window Scaling is on and truly in use and your client still hits Window Zero conditions, then what the heck is the application running for that communication? Example: IE being dog slow picking data up out of receive buffer causes Window Zero condition on large file download - update IE or get a better browser.
BTW, the Window Size field can only go to 65,535 as it is a 2-byte field. If Window Scaling is truly in use and you have set the TCP Preferences to show Relative Sequence Numbering and Window Scaling (the default), then you should see a scaled factor after the Window Size field in the communications after the first two packets of the handshake.
answered 16 Feb '11, 11:17
Usually the window scaling should be set to a value high enough to continuously transfer packets without having to stop and wait for an ACK to arrive. The bytes in flight can not exceed the effective window size.
If window scaling is enabled you'll see that both station negotiate the window scale factor in their SYN packets, which is then used to calculate the effective window size as "2 to the power of <scale factor=""> multiplied by the 'normal' 16bit window size". The latest development builds of Wireshark show both values, "normal" window size and scaled window size.
I have seen intermediate devices change the window size, resulting in a very ineffective communication (usually packet shaping or prioritizing devices, layer3 devices usually don't do this). You can check that by comparing window size and scale factors when capturing both at client and server: both should show the same values - if not, an intermediate device fumbles around with your packets.
answered 16 Feb '11, 08:33