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.
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.
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.
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.
Bob Friday, Chief AI Officer for Juniper Networks, explains how the advanced technology is transforming operations.
Contact center leaders from 8x8, Awaken Intelligence, and 360insight discuss the importance of agent experience.
AI may force enterprises to rewire parts of their data centers so they are fully optimized to run such workloads. The question is do you use Ethernet or InfiniBand?
