Talk:Bufferbloat

This is not a new problem, RFC 970 On Packet Switches With Infinite Storage http://tools.ietf.org/html/rfc970 describes the issue well.

16:34 EDT 2011-09-14 167.104.7.2 (talk) 20:36, 14 September 2011 (UTC) Note that bufferbloat != Jitter I think this subject can get its own page. but maybe i am missing a good synosym where this is already discussed. :14:58, 7 January 2011 (UTC)

This needs to be Incorporated in the article:

http://arstechnica.com/tech-policy/news/2011/01/understanding-bufferbloat-and-the-network-buffer-arms-race.ars :

He mentions that TCP congestion control—not flow control, that's something else—requires dropped packets to function, but that's not entirely true. TCP's transmission speed can be limited by the send and/or receive buffers and the round-trip time, or it can slow down because packets get lost. Both excessive buffering and excessive packet loss are unpleasant, so it's good to find some middle ground. :14:01, 10 January 2011 (UTC)

This is pretty moot: modern TCP's (anything later than Windows XP) do window scaling, and can and will fill arbitrary sized buffers with even a single TCP flowJimGettys (talk) 18:34, 19 December 2011 (UTC)

Just a note: Maybe it is worth mentioning that Control theory says that control of systems with large delays from input to measurable response is difficult and easily results in unstable systems. I find this to be a reasonable explanation for difficulties TCP etc is having with large buffer sizes. —Preceding unsigned comment added by 79.136.60.104 (talk) 02:19, 27 February 2011 (UTC)

Reducing the buffer size does _not_ eliminate the problem

"The problem can be eliminated by simply reducing the buffer size on the network hardware"

That's unfortunately not true, it is not that easy. It is true, that when you have bufferbloat, reducing the buffer size reduces the negative impact, but in practice there is no such thing as the optimal buffer size. The right buffer size always depends on the transmission rate, however usually you have multiple destinations with differing transmission rates, making it rather difficult to find the optimal buffer size. — Preceding unsigned comment added by Tddt (talk • contribs) 15:38, 24 July 2011 (UTC)

This comment is correct. JimGettys (talk) 18:34, 19 December 2011 (UTC)

This article still needs some serious rework

Oh, also note that my blog, while correct at the 95% level, has some errors; as far as I know, the ACM Queue/CACM article fixes those. This is why I enlisted Kathie Nichols to help on the paper (and Van also read it and commented on it); this area isn't an area in which I'm fully expert. So in case of contradiction, please rely on what you see in the CACM. I'm working on a much longer, more detailed paper, but it's not done yet. Maybe someday... 24.63.191.17 (talk) 21:13, 19 December 2011 (UTC)

The ACM queue article (which appeared in the January CACM), is really the best publication to date on the bufferbloat topic, and should be read and consulted by anyone who wants to take this topic on properly.

I don't have time to do this today, and it is probably more appropriate if others undertake the surgery. I may get to it, but not anytime in the next month or two. JimGettys (talk) 18:34, 19 December 2011 (UTC)

I did update the citation to the CACM article, since the dead tree version is now available. I hope this helps.

Note that it can be used as proper citation for a number of the places where the article wants citations now.

I also note about 30 articles referencing bufferbloat in the last year courtesy of Google Scholar; dunno if any of them really try to cover the topic itself, though. JimGettys (talk) 20:39, 20 February 2012 (UTC)