From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp190.iad.emailsrvr.com (smtp190.iad.emailsrvr.com [207.97.245.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id C754821F1A5 for ; Tue, 8 Jan 2013 07:04:23 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp29.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id D86C5149228; Tue, 8 Jan 2013 10:04:21 -0500 (EST) X-Virus-Scanned: OK Received: from legacy12.wa-web.iad1a (legacy12.wa-web.iad1a.rsapps.net [192.168.4.98]) by smtp29.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id AEA67148ECC; Tue, 8 Jan 2013 10:04:21 -0500 (EST) Received: from reed.com (localhost.localdomain [127.0.0.1]) by legacy12.wa-web.iad1a (Postfix) with ESMTP id 8D80612856A; Tue, 8 Jan 2013 10:04:21 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Tue, 8 Jan 2013 10:04:21 -0500 (EST) Date: Tue, 8 Jan 2013 10:04:21 -0500 (EST) From: dpreed@reed.com To: "Ingemar Johansson S" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20130108100421000000_84525" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA0801AF@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA0801AF@ESESSMB205.ericsson.se> Message-ID: <1357657461.5749402@apps.rackspace.com> X-Mailer: webmail7.0 Cc: "end2end-interest@postel.org" , "bloat@lists.bufferbloat.net" Subject: Re: [Bloat] [e2e] bufferbloat paper X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 15:04:24 -0000 ------=_20130108100421000000_84525 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A[This mail won't go to "end2end-interest" because I am blocked from post= ing 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.]=0A =0ALo= oking at your graph, Ingemar, the problem is in the extreme cases, which ar= e hardly rare. Note the scale is in *seconds* on RTT. This correlates w= ith excess buffering creating stable, extremely long queues. I've been obs= erving this for years on cellular networks - 3G, and now Verizon's deployme= nt of LTE (data collection in process).=0A =0ARegarding your lack of "exper= iencing it in wired" connections, I can only suggest this - perhaps you don= 't have any heavy load traffic sources competing for the bottleneck link.= =0A =0ATo demonstrate the bad effects of bufferbloat, I'd suggest using the= "rrul" test developed by toke@toke.dk . It simulates the "Daddy, the Inte= rnet is broken" scenario - a really heavy upload source, while measuring pi= ng-time. I submit that the kinds of times I've seen on DOCSIS cable modem= s pretty consistently is close to a second latency on the uplink, even when= the uplink is 2 Mb/sec or more.=0A =0AThe problem is that the latency due = to bufferbloat is not "random" - it is "caused", and it *can* be fixed.=0A = =0AThe first order fix is to bound the delay time through the bottleneck bu= ffer to 20 msec. or less. On a high capacity wireless link, that's appropr= iate - more would only cause the endpoint TCP to open its window wider and = wider.=0A =0A-----Original Message-----=0AFrom: "Ingemar Johansson S" =0ASent: Tuesday, January 8, 2013 2:35am=0ATo:= "end2end-interest@postel.org" , "bloat@lists.= bufferbloat.net" =0ACc: "mallman@icir.org" =0ASubject: Re: [e2e] bufferbloat paper=0A=0A=0A=0AHi=0A=0AI= nclude Mark's original post (below) as it was scrubbed=0A=0AI don't have an= data of bufferbloat for wireline access and the fiber connection that I ha= ve at home shows little evidence of bufferbloat.=0A=0AWireless access seems= to be a different story though.=0AAfter reading the "Tackling Bufferbloat = in 3G/4G Mobile Networks" by Jiang et al. I decided to make a few measureme= nts of my own (hope that the attached png is not removed) =0A=0AThe measure= ment setup was quite simple, a Laptop with Ubuntu 12.04 with a 3G modem att= ached. =0AThe throughput was computed from the wireshark logs and RTT was m= easured with ping (towards a webserver hosted by Akamai). The location is L= ule=C3=A5 city centre, Sweden (fixed locations) and the measurement was mad= e at lunchtime on Dec 6 2012 . =0A=0ADuring the measurement session I did s= ome close to normal websurf, including watching embedded videoclips and you= tube. In some cases the effects of bufferbloat was clearly noticeable. =0AA= dmit that this is just one sample, a more elaborate study with more samples= would be interesting to see.=0A=0A3G has the interesting feature that pack= ets are very seldom lost in downlink (data going to the terminal). I did no= t see a single packet loss in this test!. I wont elaborate on the reasons i= n this email.=0AI would however believe that LTE is better off in this resp= ect as long as AQM is implemented, mainly because LTE is a packet-switched = architecture.=0A=0A/Ingemar=0A=0AMarks post.=0A********=0A[I tried to post = this in a couple places to ensure I hit folks who would=0A be interested. = If you end up with multiple copies of the email, my=0A apologies. --allman= ]=0A=0AI know bufferbloat has been an interest of lots of folks recently. = So,=0AI thought I'd flog a recent paper that presents a little data on the= =0Atopic ...=0A=0A Mark Allman. Comments on Bufferbloat, ACM SIGCOMM Compu= ter=0A Communication Review, 43(1), January 2013.=0A http://www.icir.org/ma= llman/papers/bufferbloat-ccr13.pdf=0A=0AIts an initial paper. I think more= data would be great!=0A=0Aallman=0A=0A=0A--=0Ahttp://www.icir.org/mallman/= =0A=0A=0A=0A=0A ------=_20130108100421000000_84525 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= [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" li= st for those replying to me. I receive but can not send there.]

=0A

 

=0A

L= ooking at your graph, Ingemar, the problem is in the extreme cases, which a= re hardly rare.   Note the scale is in *seconds* on RTT. &nb= sp; This correlates with excess buffering creating stable, extremely long q= ueues.  I've been observing this for years on cellular networks - 3G, = and now Verizon's deployment of LTE (data collection in process).

=0A

 

=0A

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

=0A

 <= /p>=0A

To demonstrate the bad effects of bu= fferbloat, I'd suggest using the "rrul" test developed by toke@toke.dk .&nb= sp; It simulates the "Daddy, the Internet is broken" scenario - a really he= avy upload source, while measuring ping-time.   I submit that the= kinds of times I've seen on DOCSIS cable modems pretty consistently is clo= se to a second latency on the uplink, even when the uplink is 2 Mb/sec or m= ore.

=0A

 

=0A

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

=0A

 

=0A

The first order f= ix 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 wou= ld only cause the endpoint TCP to open its window wider and wider.

=0A 

=0A

-----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>, "bl= oat@lists.bufferbloat.net" <bloat@lists.bufferbloat.net>
Cc: "ma= llman@icir.org" <mallman@icir.org>
Subject: Re: [e2e] bufferbloa= t paper

=0A
=0A

Hi

Include Mark's original post (below) as i= t 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 o= f bufferbloat.

Wireless access seems to be a different story tho= ugh.
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 quit= e simple, a Laptop with Ubuntu 12.04 with a 3G modem attached.
The th= roughput was computed from the wireshark logs and RTT was measured with pin= g (towards a webserver hosted by Akamai). The location is Lule=C3=A5 city c= entre, Sweden (fixed locations) and the measurement was made at lunchtime o= n Dec 6 2012 .

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

3G has the interesting feature that packe= ts 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 re= spect as long as AQM is implemented, mainly because LTE is a packet-switche= d 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<= br /> apologies. --allman]

I know bufferbloat has been an inter= est 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-c= cr13.pdf

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

allman


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



=0A
 ------=_20130108100421000000_84525--