[Bloat] What is wrong with Microsoft's receive window auto-tuning?

[Jerry Jongerius]

I have published some more details here:

http://www.duckware.com/blog/microsoft-windows-receive-window-auto-tuning-causes-bufferbloat/index.html

The problem is that a 'receive window set too large' causes (bufferbloat and) RTT times to increase to over 200ms, which then all of sudden causes bad things to start happening when there is a lost packet.

It almost looks like the algorithm does not account for bufferbloat -- which means that during bufferbloat, RTT times increase, and the algorithm computes an even large receive window, which causes even more bufferbloat.

Just curious.  There seems to be a lot of room for improvement in the algorithms...

- Jerry


-----Original Message-----
From: Eric Dumazet [mailto:eric.dumazet at gmail.com] 
Sent: Thursday, September 11, 2014 1:06 PM
To: Jerry Jongerius
Cc: bloat at lists.bufferbloat.net
Subject: Re: [Bloat] What is wrong with Microsoft's receive window auto-tuning?

On Mon, 2014-09-01 at 13:23 -0400, Jerry Jongerius wrote:
> I am noticing (via WireShark traces) at times that Microsoft's 
> (Windows 7) receive window auto-tuning goes horribly wrong, causing 
> significant buffer bloat.  And at other times, the tuning appears to work just fine.
> 
> For example, BDP suggests a receive window of 750k, and most often 
> Windows tunes around 1MB -- but at other times, it will tune to 3.8MB 
> (way more than it should).
> 
> Is anyone aware of any research either pointing out how their tuning 
> algorithm works, or of known bugs/problems with the algorithm?

How BDP suggests a receive window of 750k ?

If BDP _is_ 750k, then 3.8 MB receive window is not insane, it depends on the amount of drops and how fast you want to recover from drops.

1MB would be to small as a matter of fact.