Re: [Bloat] Bufferbloat at LUG talk - Meeting Report

[Neil Davies <neil.davies@pnsol.com>]

Oliver 

Every TCP transfer (which may be collection of web page accesses) that reaches an instantaneous packet rate in-excess of the capacity of the most constrained network element on the path causes such problems. 

This is a measurable phenomena, it is equipment/configuration dependant - but the non-stationarity introduced is of the order of several 100ms to seconds - we've got measurements that cover that range.

Such phenomena are a natural emergent consequence of the statistical packet sharing of *any* resource.

Neil

On 12 Dec 2012, at 14:26, Oliver Hohlfeld <oliver@net.t-labs.tu-berlin.de> wrote:

>> - 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
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat