Subject: [aqm] paper: Characterizing bufferbloat from end-hosts

From: Dave Taht <[email-masked]>
Date: Fri, 21 Mar 2014 23:28:48 +0000

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 <[email-masked]> wrote:
> On Fri, Mar 21, 2014 at 10:58 PM, Fred Baker (fred) <[email-masked]> wrote:
>>
>> On Mar 21, 2014, at 3:48 PM, Dave Taht <[email-masked]> 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