<font face="times new roman" size="2"><p style="margin:0;padding:0;">[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.]</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">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).</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">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.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">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.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">The problem is that the latency due to bufferbloat is not "random" - it is "caused", and it *can* be fixed.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">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.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">-----Original Message-----<br />From: "Ingemar Johansson S" <ingemar.s.johansson@ericsson.com><br />Sent: Tuesday, January 8, 2013 2:35am<br />To: "end2end-interest@postel.org" <end2end-interest@postel.org>, "bloat@lists.bufferbloat.net" <bloat@lists.bufferbloat.net><br />Cc: "mallman@icir.org" <mallman@icir.org><br />Subject: Re: [e2e] bufferbloat paper<br /><br /></p>
<div id="SafeStyles1357656658">
<p style="margin:0;padding:0;">Hi<br /><br />Include Mark's original post (below) as it was scrubbed<br /><br />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.<br /><br />Wireless access seems to be a different story though.<br />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) <br /><br />The measurement setup was quite simple, a Laptop with Ubuntu 12.04 with a 3G modem attached. <br />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 . <br /><br />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. <br />Admit that this is just one sample, a more elaborate study with more samples would be interesting to see.<br /><br />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.<br />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.<br /><br />/Ingemar<br /><br />Marks post.<br />********<br />[I tried to post this in a couple places to ensure I hit folks who would<br /> be interested.  If you end up with multiple copies of the email, my<br /> apologies.  --allman]<br /><br />I know bufferbloat has been an interest of lots of folks recently.  So,<br />I thought I'd flog a recent paper that presents a little data on the<br />topic ...<br /><br /> Mark Allman.  Comments on Bufferbloat, ACM SIGCOMM Computer<br /> Communication Review, 43(1), January 2013.<br /> http://www.icir.org/mallman/papers/bufferbloat-ccr13.pdf<br /><br />Its an initial paper.  I think more data would be great!<br /><br />allman<br /><br /><br />--<br />http://www.icir.org/mallman/<br /><br /><br /><br /><br /></p>
</div></font>