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