[Bloat] [e2e] bufferbloat paper

Tue Jan 8 10:04:21 EST 2013

[This mail won't go to "end2end-interest" because I am blocked from posting there, but I leave the address on so that I don't narrow the "reply-to" list for those replying to me. I receive but can not send there.]

Looking at your graph, Ingemar, the problem is in the extreme cases, which are hardly rare.   Note the scale is in *seconds* on RTT.   This correlates with excess buffering creating stable, extremely long queues.  I've been observing this for years on cellular networks - 3G, and now Verizon's deployment of LTE (data collection in process).

Regarding your lack of "experiencing it in wired" connections, I can only suggest this - perhaps you don't have any heavy load traffic sources competing for the bottleneck link.

To demonstrate the bad effects of bufferbloat, I'd suggest using the "rrul" test developed by toke at toke.dk .  It simulates the "Daddy, the Internet is broken" scenario - a really heavy upload source, while measuring ping-time.   I submit that the kinds of times I've seen on DOCSIS cable modems pretty consistently is close to a second latency on the uplink, even when the uplink is 2 Mb/sec or more.

The problem is that the latency due to bufferbloat is not "random" - it is "caused", and it *can* be fixed.

The first order fix is to bound the delay time through the bottleneck buffer to 20 msec. or less.  On a high capacity wireless link, that's appropriate - more would only cause the endpoint TCP to open its window wider and wider.

-----Original Message-----
From: "Ingemar Johansson S" <ingemar.s.johansson at ericsson.com>
Sent: Tuesday, January 8, 2013 2:35am
To: "end2end-interest at postel.org" <end2end-interest at postel.org>, "bloat at lists.bufferbloat.net" <bloat at lists.bufferbloat.net>
Cc: "mallman at icir.org" <mallman at icir.org>
Subject: Re: [e2e] bufferbloat paper

Hi

Include Mark's original post (below) as it was scrubbed

I don't have an data of bufferbloat for wireline access and the fiber connection that I have at home shows little evidence of bufferbloat.

Wireless access seems to be a different story though.
After reading the "Tackling Bufferbloat in 3G/4G Mobile Networks" by Jiang et al. I decided to make a few measurements of my own (hope that the attached png is not removed) 

The measurement setup was quite simple, a Laptop with Ubuntu 12.04 with a 3G modem attached. 
The throughput was computed from the wireshark logs and RTT was measured with ping (towards a webserver hosted by Akamai). The location is Luleå city centre, Sweden (fixed locations) and the measurement was made at lunchtime on Dec 6 2012 . 

During the measurement session I did some close to normal websurf, including watching embedded videoclips and youtube. In some cases the effects of bufferbloat was clearly noticeable. 
Admit that this is just one sample, a more elaborate study with more samples would be interesting to see.

3G has the interesting feature that packets are very seldom lost in downlink (data going to the terminal). I did not see a single packet loss in this test!. I wont elaborate on the reasons in this email.
I would however believe that LTE is better off in this respect as long as AQM is implemented, mainly because LTE is a packet-switched architecture.

/Ingemar

Marks post.
********
[I tried to post this in a couple places to ensure I hit folks who would
 be interested.  If you end up with multiple copies of the email, my
 apologies.  --allman]

I know bufferbloat has been an interest of lots of folks recently.  So,
I thought I'd flog a recent paper that presents a little data on the
topic ...

 Mark Allman.  Comments on Bufferbloat, ACM SIGCOMM Computer
 Communication Review, 43(1), January 2013.
 http://www.icir.org/mallman/papers/bufferbloat-ccr13.pdf

Its an initial paper.  I think more data would be great!

allman

--
http://www.icir.org/mallman/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20130108/15140489/attachment-0003.html>