Microsoft Windows "Receive Window|
Auto-Tuning" Causes Bufferbloat
September 3, 2014 (updated 09/03/2014) - Technology Blog Index
1. Windows RWIN auto-tuning algorithm causes bufferbloat
What is wrong with Microsoft Windows receive window (RWIN) auto-tuning?
Using WireShark, I have been noticing on test downloads (PC connected directly
to cable modem) on a 120Mbps Internet connection, connecting to a server 52ms
away, that Windows 7 auto-tuning sets the receive window size to 3,841,024,
which is way higher than it should be set:
Because the BDP (Bandwidth Delay Product) suggests that a receive window around 780,000 bytes
(120Mbps/8×.052) is all that is needed.
Clearly, auto-tuning algorithms
need to tune above this level to allow for download speed variations, and potential
But Windows auto-tunes to 4.9 times (3841024/780000) the BDP -- telling me
that something is very wrong with Microsoft's auto-tuning algorithm.
Some content may be copyrighted by their respective owners and is reproduced
And the result is ever increasing bufferbloat.
As the server transmits packets and allows up to 3,841,024 bytes in unacknowledged data,
those packets must queue up somewhere, and for me, that is within the CMTS connected to
my cable modem, which then causes RTT times to dramatically increase over 200ms
for all subsequent network activity.
It is almost as if Microsoft's auto-tuning algorithm does not take into account the
side effects of setting a receive window too large (bufferbloat and increased RTT
times) and is then seeing increased RTT times and calculating a larger receive window
buffer, which itself causes even more bufferbloat, and even higher RTT times.
2. Another Windows auto-tuning bug
Looking at WireShark captures, it appears very clear that the Windows 7 auto-tuning
algorithm assumes that the congestion window on servers is initialized to 2. Where
today, most are set to 10 (see RFC6928),
and some even higher.
Why? Because for me, I always see a temporary 'stall' for one RTT, where
Windows auto-tuning has not increased the receive window quickly enough
(example seen right).
And the only thing that seems to make
sense is that if cwnd were equal to 2, then Microsoft is increasing auto-tuning
'just in time'.
Which indicates to me that Microsoft's algorithm assumes an initial
cwnd of 2.
in this paper under Title 17 Section 107 (Fair Use) of the copyright code.
The rest of this document is Copyright © 2014-2020 Jerry Jongerius