From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp141.iad.emailsrvr.com (smtp141.iad.emailsrvr.com [207.97.245.141]) (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 BFA1E21F0BD for ; Mon, 31 Dec 2012 10:44:12 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp34.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 57E4438018D for ; Mon, 31 Dec 2012 13:44:11 -0500 (EST) X-Virus-Scanned: OK Received: from legacy15.wa-web.iad1a (legacy15.wa-web.iad1a.rsapps.net [192.168.4.105]) by smtp34.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 43369380101 for ; Mon, 31 Dec 2012 13:44:11 -0500 (EST) Received: from reed.com (localhost.localdomain [127.0.0.1]) by legacy15.wa-web.iad1a (Postfix) with ESMTP id 2DE5C408001 for ; Mon, 31 Dec 2012 13:44:11 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Mon, 31 Dec 2012 13:44:11 -0500 (EST) Date: Mon, 31 Dec 2012 13:44:11 -0500 (EST) Subject: FYI - tests on Verizon LTE show significant bufferbloat From: dpreed@reed.com To: bloat-devel@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20121231134411000000_70070" Importance: Normal X-Priority: 3 (Normal) X-Type: html Message-ID: <1356979451.184121766@apps.rackspace.com> X-Mailer: webmail7.0 X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 18:44:13 -0000 ------=_20121231134411000000_70070 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0ABecause I haven't done so in a while, I decided to run Netalyzr over my = Verizon LTE phone, using it as a "mobile hotspot" through WiFi. (Netalyzr = doesn't run on Android natively, because it needs Java, which is not suppor= ted there).=0A =0AHere are the "network access link properties" I observed = from the client laptop:=0A =0Acurrent latency: 63 msec, 0% loss.=0ATCP setu= p latency: 94 msec.=0ANetwork bandwidth: uplink 2.3 Mb/sec, downlink 5.2 Mb= /sec=0ANetwork buffer measurements: uplink 3000 msec, downlink 2400 msec.= =0A =0AThis is kind of discouraging for an LTE network, since LTE is suppos= ed to be optimized for Internet data (TCP/IP), as Jim Gettys' ALU colleague= who works on LTE told me...=0A =0ANetalyzr doesn't tell me where the buffe= rs are - they might be in the phone itself (Android is based on Linux, but = unfortunately it's quite awkward to probe its internal network parameters/s= tats) or they might be in the path to/from the phone to the public Internet= .=0A =0AThis looks depressingly like the old ATT HSPA stats I measured with= a USB cable device.=0A =0AI'm going to look deeper.=0A =0AWhat do you guys= think? Should I start building a case against Verizon LTE and/or Android = as a "wifi hotspot"? We could build a "bufferbloat test app" that we put u= p on the Android Play Store. It would be a little harder to make one for A= pple - they'd probably reject it.=0A =0AOnce customers can run it, they sho= uld be able to see the numbers, and also feel the effect of bloat if a "bac= kground process" occasionally builds up a 3.0 second backlog on their uplin= k by sending 3 or 4 seconds at above 2.3 Mb/sec and then dropping down to 2= .3 Mb/sec for a minute or so.=0A =0AI realize that lots of people at IETF s= eem to still believe that bufferbloat is totally unimportant, and unnecessa= ry to fix. However, the wireless companies are, unlike cable companies, no= t local monopolies. So they might decide that competition forces them to a= ctually fix the problem, lest their competitors do so first.=0A =0A =0A =0A= =0A =0A =0A ------=_20121231134411000000_70070 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= Because I haven't done so in a while, I decided to run Netalyzr over my Ver= izon LTE phone, using it as a "mobile hotspot" through WiFi.  (Netalyz= r doesn't run on Android natively, because it needs Java, which is not supp= orted there).

=0A

 

=0A

Here are the "network access link properties" I ob= served from the client laptop:

=0A

 = ;

=0A

current latency: 63 msec, 0% loss.=

=0A

TCP setup latency: 94 msec.

=0A<= p style=3D"margin:0;padding:0;">Network bandwidth: uplink 2.3 Mb/sec, downl= ink 5.2 Mb/sec

=0A

Network buffer measur= ements: uplink 3000 msec, downlink 2400 msec.

=0A

 

=0A

This is kind of dis= couraging for an LTE network, since LTE is supposed to be optimized for Int= ernet data (TCP/IP), as Jim Gettys' ALU colleague who works on LTE told me.= ..

=0A

 

=0A

Netalyzr doesn't tell me where the buffers are - they might be= in the phone itself (Android is based on Linux, but unfortunately it's qui= te awkward to probe its internal network parameters/stats) or they might be= in the path to/from the phone to the public Internet.

=0A

 

=0A

This looks= depressingly like the old ATT HSPA stats I measured with a USB cable devic= e.

=0A

 

=0A

I'm going to look deeper.

=0A

 

=0A

What do you guys think?&nb= sp; Should I start building a case against Verizon LTE and/or Android as a = "wifi hotspot"?  We could build a "bufferbloat test app" that we put u= p on the Android Play Store.  It would be a little harder to make one = for Apple - they'd probably reject it.

=0A

 

=0A

Once customers can run it,= they should be able to see the numbers, and also feel the effect of bloat = if a "background process" occasionally builds up a 3.0 second backlog on th= eir uplink by sending 3 or 4 seconds at above 2.3 Mb/sec and then dropping = down to 2.3 Mb/sec for a minute or so.

=0A

 

=0A

I realize that lots of peo= ple at IETF seem to still believe that bufferbloat is totally unimportant, = and unnecessary to fix.  However, the wireless companies are, unlike c= able companies, not local monopolies.  So they might decide that compe= tition forces them to actually fix the problem, lest their competitors do s= o first.

=0A

 

=0A

 

=0A

 

= =0A

 

=0A

 

=0A

 

=0A

 

 ------=_20121231134411000000_70070--