[Bloat] Bufferbloat at LUG talk - Meeting Report

[Oliver Hohlfeld]

> - Attempting to Skype with a bunch of web browser tabs open gives bad results. Closing the tabs made things better. (They been blaming the browser for "using too much memory". Now it's possible to think that it's a network problem.)

Sorry to be nitpicking on this, but what evidence / indications tells
this is a networking problem? Why would the pages in the open tabs
constantly sent large bulks of data that fill up the buffers? While
there is certainly asynchronous communication over HTTP (Ajax etc.), I'm
talking about traffic demands that can interfere with VoIP. This seems
highly unlikely. Correlating every possible problem with bufferbloat
without further investigation doesn't make any sense to me.

> - Another person reported that his network connection (wireless ISP, two hops to a wired network) seemed to work OK as long as his household was mostly downloading. But uploading much of anything really made things bad.

This is a known fact. Even Gettys reported this issue in his first paper.

> I posted the slides at http://www.bufferbloat.net/attachments/download/148/Bufferbloat-DLSLUG-Dec2012.pdf

Thanks for sharing this!

A few comments:

- Slide 12 reads wired to me. It assumes that the entire main memory is
allocated to packet memory. How will the home router then run an OS and
any sort of application on top of it? The argument is flawed.

- Codel and SFQ are not the only solutions to improve bad FIFO queues.
Simple QoS mechanisms will do the trick as well (briefly mentioned on
slide 12).

- Slide 14 presents a long list of devices that lack of implementations.
While the problem has been demonstrated for the first half of the list,
I'd be interested to see if Codel could improve DSLAMs and cable
headends, that, to the best of my knowledge, hardly queue traffic and do
not induce significant queuing delays.

Oliver