From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp120.iad.emailsrvr.com (smtp120.iad.emailsrvr.com [207.97.245.120]) (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 2679421F1A5 for ; Tue, 8 Jan 2013 07:29:37 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp42.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 71F94280254; Tue, 8 Jan 2013 10:29:35 -0500 (EST) X-Virus-Scanned: OK Received: from legacy13.wa-web.iad1a (legacy13.wa-web.iad1a.rsapps.net [192.168.4.99]) by smtp42.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 18DC2148893; Tue, 8 Jan 2013 10:29:35 -0500 (EST) Received: from reed.com (localhost.localdomain [127.0.0.1]) by legacy13.wa-web.iad1a (Postfix) with ESMTP id 03A4B37040E; Tue, 8 Jan 2013 10:29:35 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Tue, 8 Jan 2013 10:29:35 -0500 (EST) Date: Tue, 8 Jan 2013 10:29:35 -0500 (EST) From: dpreed@reed.com To: "Ingemar Johansson S" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20130108102935000000_17168" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA08050D@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA0801AF@ESESSMB205.ericsson.se> <81564C0D7D4D2A4B9A86C8C7404A13DA080493@ESESSMB205.ericsson.se> <81564C0D7D4D2A4B9A86C8C7404A13DA08050D@ESESSMB205.ericsson.se> Message-ID: <1357658975.013413296@apps.rackspace.com> X-Mailer: webmail7.0 Cc: Keith Winstein , "bloat@lists.bufferbloat.net" , "end2end-interest@postel.org" 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:29:38 -0000 ------=_20130108102935000000_17168 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0ARe: "the only thing that counts is peak throughput" - it's a pretty cyni= cal stance to say "I'm a professional engineer, but the marketing guys don'= t have a clue, so I'm not going to build a usable system".=0A =0AIt's even = worse when fellow engineers *disparage* or downplay the work of engineers w= ho are actually trying hard to fix this across the entire Internet.=0A =0AD= oes competition require such foolishness? Have any of the folks who work = for operators and equipment suppliers followed Richard Woundy's lead (he is= SVP at Comcast) and tried to *fix* the problem and get the fix deployed. = Richard is an engineer, and took the time to develop a proposed fix to DOCS= IS 3.0, and also to write a "best practices" document about how to deploy t= hat fix. The one thing he could not do is get Comcast or its competitors t= o invest money in deploying the fix more rapidly.=0A =0AFirst, it's importa= nt to measure the "right thing" - which in this case is "how much queueing = *delay* builds up in the bottleneck link under load" and how bad is the use= r experience when that queueing delay stabilizes at more than about 20 msec= .=0A =0AThat cannot be determined by measuring throughput, which is all the= operators measure. (I have the sworn testimony of every provider in Canad= a when asked by the CRTC "do you measure latency on your internet service",= the answer was uniformly - we measure throughput *only*, and by Little's L= emma we can determine latency).=0A =0AEngineers actually have a positive du= ty to society, not just to profits. And actually, in this case, better ser= vice *would* lead to more profits! Not directly, but because there is comp= etition for experience, even more than for "bitrate", despite the claims of= engineers.=0A =0ASo talk to your CEO's. When I've done so, they say they = have *never* heard of the issue. Maybe that's due to denial throughout the= organization.=0A =0A(by the way, what woke Comcast up was getting hauled i= n front of the FCC for deploying DPI-based RST injection that disrupted lar= ge classes of connections - because they had not realized what their proble= m was, and the marketers wanted to blame "pirates" for clogging the circuit= s - for which claim they had no data other than self-serving and proprietar= y "studies" from the vendors like Sandvine and Ellacoya).=0A =0AActual meas= urements of actual network behavior revealed the bufferbloat phenomenon was= the cause of disruptive events due to load in *every* case observed by me,= and I've looked at a lot. It used to happen on Frame Relay links all the = time, and in datacenter TCP/IP internal deployments.=0A =0ASo measure first= . Measure the right thing (latency growth under load). Ask "why is this h= appening?" and don't jump to the non sequitur (pirates or "interference") = without proving that the non sequitur actually explains the entire phenomen= on (something Comcast failed to do, instead reasoning from anecdotal links = between bittorrent and the problem.=0A =0AAnd then when your measurements a= re right, and you can demonstrate a solution that *works* (rather than some= thing that in academia would be an "interesting Ph.D. proposal"), then depl= oy it and monitor it.=0A =0A =0A =0A-----Original Message-----=0AFrom: "Ing= emar Johansson S" =0ASent: Tuesday, Janua= ry 8, 2013 8:19am=0ATo: "Keith Winstein" =0ACc: "mallman@ic= ir.org" , "end2end-interest@postel.org" , "bloat@lists.bufferbloat.net" = =0ASubject: Re: [e2e] bufferbloat paper=0A=0A=0A=0AOK...=0A=0ALikely means = that AQM is not turned on in the eNodeB, can't be 100% sure though but it s= eems so.=0AAt least one company I know of offers AQM in eNodeB. However on= e problem seems to be that the only thing that counts is peak throughput, y= ou have probably too seen these "up to X Mbps" slogans. Competition is fie= rce snd for this reason it could be tempting to turn off AQM as it may redu= ce peak throughput slightly. I know and most people on these mailing lists = knows that peak throughput is the "mexapixels" of the internet, one need to= address other aspects in the benchmarks.=0A=0A/Ingemar=0A=0A=0A> -----Orig= inal Message-----=0A> From: winstein@gmail.com [mailto:winstein@gmail.com] = On Behalf Of Keith=0A> Winstein=0A> Sent: den 8 januari 2013 13:44=0A> To: = Ingemar Johansson S=0A> Cc: end2end-interest@postel.org; bloat@lists.buffer= bloat.net;=0A> mallman@icir.org=0A> Subject: Re: [e2e] bufferbloat paper=0A= > =0A> Hello Ingemar,=0A> =0A> Thanks for your feedback and your own graph.= =0A> =0A> This is testing the LTE downlink, not the uplink. It was a TCP do= wnload.=0A> =0A> There was zero packet loss on the ICMP pings. I did not me= asure the TCP=0A> flow itself but I suspect packet loss was minimal if not = also zero.=0A> =0A> Best,=0A> Keith=0A> =0A> On Tue, Jan 8, 2013 at 7:19 AM= , Ingemar Johansson S=0A> wrote:=0A> > H= i=0A> >=0A> > Interesting graph, thanks for sharing it.=0A> > It is likely = that the delay is only limited by TCPs maximum congestion=0A> window, for i= nstance at T=3D70 the thoughput is ~15Mbps and the RTT~0.8s,=0A> giving a c= ongestion window of 1.5e7/8/0.8 =3D 2343750 bytes, recalculations at=0A> ot= her time instants seems to give a similar figure.=0A> > Do you see any pack= et loss ?=0A> >=0A> > The easiest way to mitigate bufferbloat in LTE UL is = AQM in the terminal as=0A> the packets are buffered there.=0A> > The eNodeB= does not buffer up packets in UL* so I would in this particular=0A> case a= rgue that the problem is best solved in the terminal.=0A> > Implementing AQ= M for UL in eNodeB is probably doable but AFAIK nothing=0A> that is standar= dized also I cannot tell how feasible it is.=0A> >=0A> > /Ingemar=0A> >=0A>= > BTW... UL =3D uplink=0A> > * RLC-AM retransmissions can be said to cause= delay in the eNodeB but=0A> then again the main problem is that packets ar= e being queued up in the=0A> terminals sendbuffer. The MAC layer HARQ can t= oo cause some delay but=0A> this is a necessity to get an optimal performan= ce for LTE, moreover the=0A> added delay due to HARQ reTx is marginal in th= is context.=0A> >=0A> >> -----Original Message-----=0A> >> From: winstein@g= mail.com [mailto:winstein@gmail.com] On Behalf Of=0A> >> Keith Winstein=0A>= >> Sent: den 8 januari 2013 11:42=0A> >> To: Ingemar Johansson S=0A> >> Cc= : end2end-interest@postel.org; bloat@lists.bufferbloat.net;=0A> >> mallman@= icir.org=0A> >> Subject: Re: [e2e] bufferbloat paper=0A> >>=0A> >> I'm sorr= y to report that the problem is not (in practice) better on=0A> >> LTE, eve= n though the standard may support features that could be used=0A> >> to mit= igate the problem.=0A> >>=0A> >> Here is a plot (also at=0A> >> http://web.= mit.edu/keithw/www/verizondown.png)=0A> >> from a computer tethered to a Sa= msung Galaxy Nexus running Android=0A> >> 4.0.4 on Verizon LTE service, tak= en just now in Cambridge, Mass.=0A> >>=0A> >> The phone was stationary duri= ng the test and had four bars (a full=0A> >> signal) of "4G" service. The c= omputer ran a single full-throttle TCP=0A> >> CUBIC download from one well-= connected but unremarkable Linux host=0A> >> (ssh hostname 'cat /dev/urando= m') while pinging at 4 Hz across the=0A> >> same tethered LTE interface. Th= ere were zero lost pings during the=0A> >> entire test=0A> >> (606/606 deli= vered).=0A> >>=0A> >> The RTT grows to 1-2 seconds and stays stable in that= region for most=0A> >> of the test, except for one 12-second period of >5 = seconds RTT. We=0A> >> have also tried measuring only "one-way delay" (inst= ead of RTT) by=0A> >> sending UDP datagrams out of the computer's Ethernet = interface over=0A> >> the Internet, over LTE to the cell phone and back to = the originating=0A> >> computer via USB tethering. This gives similar resul= ts to ICMP ping.=0A> >>=0A> >> I don't doubt that the carriers could implem= ent reasonable AQM or=0A> >> even a smaller buffer at the head-end, or that= the phone could=0A> >> implement AQM for the uplink. For that matter I'm n= ot sure the details of=0A> the air interface (LTE vs.=0A> >> UMTS vs. 1xEV-= DO) necessarily makes a difference here.=0A> >>=0A> >> But at present, at l= east with AT&T, Verizon, Sprint and T-Mobile in=0A> >> Eastern Massachusett= s, the carrier is willing to queue and hold on to=0A> >> packets for >1 sec= ond. Even a single long-running TCP download (>15=0A> >> megabytes) is enou= gh to tickle this problem.=0A> >>=0A> >> In the CCR paper, even flows >1 me= gabyte were almost nonexistent,=0A> >> which may be part of how these findi= ngs are compatible.=0A> >>=0A> >> On Tue, Jan 8, 2013 at 2:35 AM, Ingemar J= ohansson S=0A> >> wrote:=0A> >> > Hi=0A>= >> >=0A> >> > Include Mark's original post (below) as it was scrubbed=0A> = >> >=0A> >> > I don't have an data of bufferbloat for wireline access and t= he=0A> >> > fiber=0A> >> connection that I have at home shows little eviden= ce of bufferbloat.=0A> >> >=0A> >> > Wireless access seems to be a differen= t story though.=0A> >> > After reading the "Tackling Bufferbloat in 3G/4G M= obile Networks"=0A> >> > by Jiang et al. I decided to make a few measuremen= ts of my own=0A> >> > (hope that the attached png is not removed)=0A> >> >= =0A> >> > The measurement setup was quite simple, a Laptop with Ubuntu 12.0= 4=0A> >> with a 3G modem attached.=0A> >> > The throughput was computed fro= m the wireshark logs and RTT was=0A> >> measured with ping (towards a webse= rver hosted by Akamai). The=0A> >> location is Lule=C3=A5 city centre, Swed= en (fixed locations) and the=0A> >> measurement was made at lunchtime on De= c 6 2012 .=0A> >> >=0A> >> > During the measurement session I did some clos= e to normal websurf,=0A> >> including watching embedded videoclips and yout= ube. In some cases the=0A> >> effects of bufferbloat was clearly noticeable= .=0A> >> > Admit that this is just one sample, a more elaborate study with= =0A> >> > more=0A> >> samples would be interesting to see.=0A> >> >=0A> >> = > 3G has the interesting feature that packets are very seldom lost in=0A> >= > downlink (data going to the terminal). I did not see a single packet=0A> = >> loss in this test!. I wont elaborate on the reasons in this email.=0A> >= > > I would however believe that LTE is better off in this respect as=0A> >= > > long as=0A> >> AQM is implemented, mainly because LTE is a packet-switc= hed=0A> architecture.=0A> >> >=0A> >> > /Ingemar=0A> >> >=0A> >> > Marks po= st.=0A> >> > ********=0A> >> > [I tried to post this in a couple places to = ensure I hit folks who=0A> >> > would be interested. If you end up with m= ultiple copies of the=0A> >> > email, my apologies. --allman]=0A> >> >=0A= > >> > I know bufferbloat has been an interest of lots of folks recently.= =0A> >> > So, I thought I'd flog a recent paper that presents a little data= =0A> >> > on the topic ...=0A> >> >=0A> >> > Mark Allman. Comments on = Bufferbloat, ACM SIGCOMM Computer=0A> >> > Communication Review, 43(1),= January 2013.=0A> >> > http://www.icir.org/mallman/papers/bufferbloat-= ccr13.pdf=0A> >> >=0A> >> > Its an initial paper. I think more data would = be great!=0A> >> >=0A> >> > allman=0A> >> >=0A> >> >=0A> >> > --=0A> >> > h= ttp://www.icir.org/mallman/=0A> >> >=0A> >> >=0A> >> >=0A> >> >=0A=0A ------=_20130108102935000000_17168 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= Re: "the only thing that counts is peak throughput" - it's a pretty cynical= stance to say "I'm a professional engineer, but the marketing guys don't h= ave a clue, so I'm not going to build a usable system".

=0A

 

=0A

It's even= worse when fellow engineers *disparage* or downplay the work of engineers = who are actually trying hard to fix this across the entire Internet.

=0A=

 

=0A

Does competition require such foolishness?   Have any of the = folks who work for operators and equipment suppliers followed Richard Wound= y's lead (he is SVP at Comcast) and tried to *fix* the problem and get the = fix deployed.  Richard is an engineer, and took the time to develop a = proposed fix to DOCSIS 3.0, and also to write a "best practices" document a= bout how to deploy that fix.  The one thing he could not do is get Com= cast or its competitors to invest money in deploying the fix more rapidly.<= /p>=0A

 

=0A

First, it's important to measure the "right thing" - which in thi= s case is "how much queueing *delay* builds up in the bottleneck link under= load" and how bad is the user experience when that queueing delay stabiliz= es at more than about 20 msec.

=0A

 = ;

=0A

That cannot be determined by measu= ring throughput, which is all the operators measure.  (I have the swor= n testimony of every provider in Canada when asked by the CRTC "do you meas= ure latency on your internet service", the answer was uniformly - we measur= e throughput *only*, and by Little's Lemma we can determine latency).

= =0A

 

=0A

Engineers actually have a positive duty to society, not just to prof= its.  And actually, in this case, better service *would* lead to more = profits!  Not directly, but because there is competition for experienc= e, even more than for "bitrate", despite the claims of engineers.

=0A

 

=0A

So talk to your CEO's.  When I've done so, they say they have *never*= heard of the issue.  Maybe that's due to denial throughout the organi= zation.

=0A

 

=0A

(by the way, what woke Comcast up was getting hauled in f= ront of the FCC for deploying DPI-based RST injection that disrupted large = classes of connections - because they had not realized what their problem w= as, and the marketers wanted to blame "pirates" for clogging the circuits -= for which claim they had no data other than self-serving and proprietary "= studies" from the vendors like Sandvine and Ellacoya).

=0A

 

=0A

Actual mea= surements of actual network behavior revealed the bufferbloat phenomenon wa= s the cause of disruptive events due to load in *every* case observed by me= , and I've looked at a lot.  It used to happen on Frame Relay links al= l the time, and in datacenter TCP/IP internal deployments.

=0A

 

=0A

So m= easure first.  Measure the right thing (latency growth under load).&nb= sp; Ask "why is this happening?"  and don't jump to the non sequitur (= pirates or "interference") without proving that the non sequitur actually e= xplains the entire phenomenon (something Comcast failed to do, instead reas= oning from anecdotal links between bittorrent and the problem.

=0A

 

=0A

An= d then when your measurements are right, and you can demonstrate a solution= that *works* (rather than something that in academia would be an "interest= ing Ph.D. proposal"), then deploy it and monitor it.

=0A

 

=0A

 

= =0A

 

=0A

-----Original Message-----
From: "Ingemar Johansson S" <inge= mar.s.johansson@ericsson.com>
Sent: Tuesday, January 8, 2013 8:19am=
To: "Keith Winstein" <keithw@mit.edu>
Cc: "mallman@icir.or= g" <mallman@icir.org>, "end2end-interest@postel.org" <end2end-inte= rest@postel.org>, "bloat@lists.bufferbloat.net" <bloat@lists.bufferbl= oat.net>
Subject: Re: [e2e] bufferbloat paper

=0A=0A

OK...

Likely means that AQM is not turned on in the eNodeB, can't be 100%= sure though but it seems so.
At least one company I know of offers A= QM in eNodeB. However one problem seems to be that the only thing that coun= ts is peak throughput, you have probably too seen these "up to X Mbps" slog= ans. Competition is fierce snd for this reason it could be tempting to tur= n off AQM as it may reduce peak throughput slightly. I know and most people= on these mailing lists knows that peak throughput is the "mexapixels" of t= he internet, one need to address other aspects in the benchmarks.

/Ingemar


> -----Original Message-----
> From:= winstein@gmail.com [mailto:winstein@gmail.com] On Behalf Of Keith
>= ; Winstein
> Sent: den 8 januari 2013 13:44
> To: Ingemar J= ohansson S
> Cc: end2end-interest@postel.org; bloat@lists.bufferblo= at.net;
> mallman@icir.org
> Subject: Re: [e2e] bufferbloat= paper
>
> Hello Ingemar,
>
> Thanks for = your feedback and your own graph.
>
> This is testing the = LTE downlink, not the uplink. It was a TCP download.
>
> T= here was zero packet loss on the ICMP pings. I did not measure the TCP
> flow itself but I suspect packet loss was minimal if not also zero.>
> Best,
> Keith
>
> On Tue, Jan = 8, 2013 at 7:19 AM, Ingemar Johansson S
> <ingemar.s.johansson@e= ricsson.com> wrote:
> > Hi
> >
> > Inte= resting graph, thanks for sharing it.
> > It is likely that the = delay is only limited by TCPs maximum congestion
> window, for inst= ance at T=3D70 the thoughput is ~15Mbps and the RTT~0.8s,
> giving = a congestion window of 1.5e7/8/0.8 =3D 2343750 bytes, recalculations at
> other time instants seems to give a similar figure.
> > D= o you see any packet loss ?
> >
> > The easiest way t= o mitigate bufferbloat in LTE UL is AQM in the terminal as
> the pa= ckets are buffered there.
> > The eNodeB does not buffer up pack= ets in UL* so I would in this particular
> case argue that the prob= lem is best solved in the terminal.
> > Implementing AQM for UL = in eNodeB is probably doable but AFAIK nothing
> that is standardiz= ed also I cannot tell how feasible it is.
> >
> > /In= gemar
> >
> > BTW... UL =3D uplink
> > * R= LC-AM retransmissions can be said to cause delay in the eNodeB but
>= ; then again the main problem is that packets are being queued up in the> terminals sendbuffer. The MAC layer HARQ can too cause some delay b= ut
> this is a necessity to get an optimal performance for LTE, mor= eover the
> added delay due to HARQ reTx is marginal in this contex= t.
> >
> >> -----Original Message-----
> &= gt;> From: winstein@gmail.com [mailto:winstein@gmail.com] On Behalf Of> >> Keith Winstein
> >> Sent: den 8 januari 201= 3 11:42
> >> To: Ingemar Johansson S
> >> Cc: e= nd2end-interest@postel.org; bloat@lists.bufferbloat.net;
> >>= mallman@icir.org
> >> Subject: Re: [e2e] bufferbloat paper> >>
> >> I'm sorry to report that the problem i= s not (in practice) better on
> >> LTE, even though the stand= ard may support features that could be used
> >> to mitigate = the problem.
> >>
> >> Here is a plot (also at<= br />> >> http://web.mit.edu/keithw/www/verizondown.png)
>= >> from a computer tethered to a Samsung Galaxy Nexus running Androi= d
> >> 4.0.4 on Verizon LTE service, taken just now in Cambri= dge, Mass.
> >>
> >> The phone was stationary d= uring the test and had four bars (a full
> >> signal) of "4G"= service. The computer ran a single full-throttle TCP
> >> CU= BIC download from one well-connected but unremarkable Linux host
> = >> (ssh hostname 'cat /dev/urandom') while pinging at 4 Hz across the=
> >> same tethered LTE interface. There were zero lost pings= during the
> >> entire test
> >> (606/606 deli= vered).
> >>
> >> The RTT grows to 1-2 seconds = and stays stable in that region for most
> >> of the test, ex= cept for one 12-second period of >5 seconds RTT. We
> >> h= ave also tried measuring only "one-way delay" (instead of RTT) by
>= >> sending UDP datagrams out of the computer's Ethernet interface ov= er
> >> the Internet, over LTE to the cell phone and back to = the originating
> >> computer via USB tethering. This gives s= imilar results to ICMP ping.
> >>
> >> I don't = doubt that the carriers could implement reasonable AQM or
> >>= ; even a smaller buffer at the head-end, or that the phone could
> = >> implement AQM for the uplink. For that matter I'm not sure the det= ails of
> the air interface (LTE vs.
> >> UMTS vs. 1x= EV-DO) necessarily makes a difference here.
> >>
> &g= t;> But at present, at least with AT&T, Verizon, Sprint and T-Mobile= in
> >> Eastern Massachusetts, the carrier is willing to que= ue and hold on to
> >> packets for >1 second. Even a singl= e long-running TCP download (>15
> >> megabytes) is enough= to tickle this problem.
> >>
> >> In the CCR p= aper, even flows >1 megabyte were almost nonexistent,
> >>= which may be part of how these findings are compatible.
> >>=
> >> On Tue, Jan 8, 2013 at 2:35 AM, Ingemar Johansson S
> >> <ingemar.s.johansson@ericsson.com> wrote:
> &= gt;> > Hi
> >> >
> >> > Include Mar= k's original post (below) as it was scrubbed
> >> >
&= gt; >> > I don't have an data of bufferbloat for wireline access a= nd the
> >> > fiber
> >> connection that I h= ave 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 attache= d png is not removed)
> >> >
> >> > The m= easurement 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 wi= th ping (towards a webserver hosted by Akamai). The
> >> loca= tion is Lule=C3=A5 city centre, Sweden (fixed locations) and the
> = >> measurement was made at lunchtime on Dec 6 2012 .
> >&g= t; >
> >> > During the measurement session I did some c= lose to normal websurf,
> >> including watching embedded vide= oclips and youtube. In some cases the
> >> effects of bufferb= loat was clearly noticeable.
> >> > Admit that this is jus= t one sample, a more elaborate study with
> >> > more
> >> samples would be interesting to see.
> >> >=
> >> > 3G has the interesting feature that packets are ve= ry seldom lost in
> >> downlink (data going to the terminal).= I did not see a single packet
> >> loss in this test!. I won= t elaborate on the reasons in this email.
> >> > I would h= owever believe that LTE is better off in this respect as
> >>= > long as
> >> AQM is implemented, mainly because LTE is = a packet-switched
> architecture.
> >> >
>= >> > /Ingemar
> >> >
> >> > Mar= ks 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]
> >> &g= t;
> >> > 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 ...<= br />> >> >
> >> > Mark Allman. Comments = on Bufferbloat, ACM SIGCOMM Computer
> >> > Communicat= ion Review, 43(1), January 2013.
> >> > http://www.ici= r.org/mallman/papers/bufferbloat-ccr13.pdf
> >> >
>= ; >> > Its an initial paper. I think more data would be great!> >> >
> >> > allman
> >> >= ;
> >> >
> >> > --
> >> >= ; http://www.icir.org/mallman/
> >> >
> >> &= gt;
> >> >
> >> >

=0A ------=_20130108102935000000_17168--