Network Analysis: TCP Window Size

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.

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.

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.

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.