[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@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@ericsson.com>
Sent: Tuesday, January 8, 2013 2:35am
To: "end2end-interest@postel.org" <end2end-interest@postel.org>, "bloat@lists.bufferbloat.net" <bloat@lists.bufferbloat.net>
Cc: "mallman@icir.org" <mallman@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/