Network Analysis: TCP Window Size

Tony Fortunato demonstrates how to track TCP window size to troubleshoot network performance issues.

Tony Fortunato

November 17, 2016

2 Min Read
Network Computing logo

TCP window size is one of the most popular options for network troubleshooting or performing an application baseline. I’ve read many articles and books that can make this option quite overwhelming, but it's actually pretty straightforward.

The TCP window size, or as some call it, the TCP receiver  window size, is simply an advertisement of how much data (in bytes) the receiving device is willing to receive at any point in time. The receiving device can use this value to control the flow of data, or as a flow control mechanism.

Some operating systems will use a multiple of their maximum segment size (MSS) to calculate the maximum TCP window size. For example, in Microsoft Windows 2000 on Ethernet networks, the default value is 17,520 bytes, or 12 MSS segments of 1,460 bytes each. I suggest you document your system's default since it can change when installing an application.

Pay close attention if the operating system uses TCP scaling option since it will increase the total TCP window size by providing a multiplier value. Check your network protocol analyzer and figure out if you can provide the TCP scaling value manually in case you do not have the SYN packets. In the video below, I cover how to do this using Wireshark 2.0:

In the screenshot below, this packet has a scaling value of eight, which is converted to 256. The math is quite straightforward: two to the factor (or power) of eight, which is 256.

null

window size-1.png

 

In situations when the receiver is overwhelmed, it will advertise a zero window size. There are circumstances where this can be expected, such as a printer since it has a mechanical limitation and can only buffer so much, or a truly overloaded system.

When this scenario occurs, I measure the "TCP recovery time." This is the time it takes for the receiver to go from a zero value to at least one MSS value in a TCP Window Update. In the screenshot below you can see that it took the receiver more than two seconds to "recover" from a zero condition.

null

window size-2.png

 

Look for TCP ZeroWindowProbe packets (screenshot below) since they help prove that the sender recognizes the receiver has indicated its TCP Window size is zero, but is trying to get the flow going again. The existence of TCP ZeroWindowProbeAck packets also indicates that the network is delivering packets and the devices are not down.

null

windows-3.png

 

When trying to resolve TCP window size issues, common fixes  are worth trying such as increasing RAM or a faster processor. Increasing your TCP window size on the device reporting a TCP zero window also is worthwhile.

If you would like to calculate what the TCP window size should be, there are many websites and applications that can help calculate what these values should be. I like Speedguide.net’s TCP/IP Analyzer and TCP Optimizer.

About the Author(s)

Tony Fortunato

Sr Network Performance Specialist

Tony Fortunato is a network performance expert who has been designing, implementing and troubleshooting networks since 1989. His company, The Technology Firm, provides clients of all sizes with services ranging from project management, network design, consulting, troubleshooting, designing custom-designed training courses, and assisting with equipment installation. Tony's experience in networking started with financial trading floor networks and ISPs, where he learned to integrate and support equipment from various vendors. Tony has taught and presented at numerous colleges and universities, public forums and private classes. He blogs frequently at NetworkDataPediaand has a popular YouTube channel.

SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox

You May Also Like


More Insights