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.
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.