From: "Jerry Jongerius" <jerryj@duckware.com>
To: "'Eric Dumazet'" <eric.dumazet@gmail.com>
Cc: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] What is wrong with Microsoft's receive window auto-tuning?
Date: Fri, 12 Sep 2014 07:03:53 -0400 [thread overview]
Message-ID: <000101cfce79$3f6e1f60$be4a5e20$@duckware.com> (raw)
In-Reply-To: <1410455146.7106.55.camel@edumazet-glaptop2.roam.corp.google.com>
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@gmail.com]
Sent: Thursday, September 11, 2014 1:06 PM
To: Jerry Jongerius
Cc: bloat@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.
prev parent reply other threads:[~2014-09-12 11:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-01 17:23 Jerry Jongerius
2014-09-11 17:05 ` Eric Dumazet
2014-09-11 17:40 ` Steinar H. Gunderson
2014-09-11 21:13 ` Eric Dumazet
2014-09-12 11:03 ` Jerry Jongerius [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000101cfce79$3f6e1f60$be4a5e20$@duckware.com' \
--to=jerryj@duckware.com \
--cc=bloat@lists.bufferbloat.net \
--cc=eric.dumazet@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox