I look forward to seeing what hosts and networks were analyzed in this upcoming paper april 14th.
http://networks.eecs.qmul.ac.uk/news/tma-2014/program/ Unfortunately the video of the presentation is not (yet?) available: https://www.lincs.fr/events/characterizing-bufferbloat-end-hosts/ But the description was promising: Abstract "While, on routers and gateways, buffers on forwarding devices are required to handle bursty Internet traffic, overly large or badly sized buffers can interact with TCP in undesirable ways. This phenomenon is well understood and is often called bufferbloat. Although a number of previous studies have shown that buffering (particularly, in home) can delay packets by as much as a few seconds in the worst case, there is less empirical evidence of tangible impacts on end-users. In this paper, we develop a modified algorithm that can detect bufferbloat at individual end-hosts based on passive observations of traffic. We then apply this algorithm on packet traces collected at 55 end- hosts, and across different network environments. Our results show that 45 out of the 55 users we study experience bufferbloat at least once, 40% of these users experience bufferbloat more than once per hour. In 90% of cases, buffering more than doubles RTTs, but RTTs during bufferbloat are rarely over one second. We also show that web and interactive applications, which are particularly sensitive to delay, are the applications most often affected by bufferbloat." I hope they clearly identify what isps and technologies were under test. On Fri, Mar 21, 2014 at 11:04 PM, Dave Taht <dave.t...@gmail.com> wrote: > On Fri, Mar 21, 2014 at 10:58 PM, Fred Baker (fred) <f...@cisco.com> wrote: >> >> On Mar 21, 2014, at 3:48 PM, Dave Taht <dave.t...@gmail.com> wrote: >> >>> [3] any chance we could get rrul test out of your 12/2 mbit link to >>> establish its characteristics under load? >> >> Without, of course, taking it out of service... It's not a lab, it's a Cox >> link that serves my home and therefore my home office. > > For 60 seconds your line will suck. But think of the data! > > Nearest rrul server to you is snapon.lab.bufferbloat.net > > rrul code (also requiring netperf and fping) is at: > > https://github.com/tohojo/netperf-wrapper > >> And without saying what equipment, or configuration, is at my end, and >> without knowing what is at Cox's end. > > While it's nice to know some details on your connection (I hope you are > running > RED as well?), merely having a benchmark is useful. > >> Your point is...? > > We have tens of thousands of rrul tests now and at least toke and I > find it very useful > to look at the results from as wide a range of bandwidths, RTTs, and media > types > as possible. At this point I can pick out by eye what sort of > connection I'm looking > at - be it dsl, wifi, fiber, or cable.... > > toke is adding d-itg support to it so as to also be better able to > emulate voip under load. > -- > Dave Täht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
