All,
After lots of packet captures I have found the my slow throughput issue is due to a small window size. The scale is only at 4.
I know that the Window size scaling factor comes form the host using BDP (bandwidth X latency)
How does the host know its bandwidth? Does it use it nic card settings?
Hi, refer to this quite detailed article
So assuming you have Windows OS it controls RWIN size based on 2 factors: interface speed and selected Receive Window autotuning level:
"...So, as summary, the different states for AutoTuningLevel are as follows:
Normal (Default): 0x8 (Scale Factor of 8)
Restricted: 0x4 (Scale Factor of 4)
Highly Restricted: 0x2 (Scale Factor of 2)
Disable: No scale factor available
Experimental: 0xE (Scale Factor of 14)..."
Later, after connection is established, Windows OS uses current receive rate to update RWIN size accourdingly (unlike Scaling factor which is set in SYN packets, we can change RWIN size all the time connection is active).
I've just checked my Win 10 with 'Normal' autotuning level and indeed it shooses Scale Factor of 8 in every TCP connection.
Also as Jim said before it'd be nice to see PCAP and check if it is exactly the reason of low throughput.
This seems to be a spin-off of throughput issue dropped packet slow start discussing an iperf performance test over a 70+ms latency path. Links to the captures are available there ...
Asked: 2018-07-16 16:18:51 +0000
Seen: 469 times
Last updated: Jul 17 '18
Copyright Wireshark Foundation, 2017-2023 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
What makes you conclude that small window sizes are the problem?
When you say:
do you mean the Window Scaling shift factor, or the resulting multiplier?
A multiplier of 4 (which results from a shift factor of 2), allows the host to advertise a window size of up to 262,140 bytes. A shift factor of 4 results in a multiplier of 16 and allows the host to advertise a window size of up to 1,048,560 bytes.
The Window Scaling factor limits the maximum window size that a host can advertise, but does not determine the actual window size that it uses. It's useful to know the scaling factor, but only in order to calculate what window sizes the host is actually advertising. In order to correctly calculate the actual window sizes, the capture has to include the TCP three-way handshake ...(more)
Yes he knows his own bandwitdth by reading the NIC card setting. This setting is either negotiated or manually set. And the host does not know anythging about some bottlenecks on the path.