> - 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
