<font face="times new roman" size="2"><p style="margin:0;padding:0;">Because 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 supported there).</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">Here are the "network access link properties" I observed from the client laptop:</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">current latency: 63 msec, 0% loss.</p>
<p style="margin:0;padding:0;">TCP setup latency: 94 msec.</p>
<p style="margin:0;padding:0;">Network bandwidth: uplink 2.3 Mb/sec, downlink 5.2 Mb/sec</p>
<p style="margin:0;padding:0;">Network buffer measurements: uplink 3000 msec, downlink 2400 msec.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">This is kind of discouraging for an LTE network, since LTE is supposed to be optimized for Internet data (TCP/IP), as Jim Gettys' ALU colleague who works on LTE told me...</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">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 quite awkward to probe its internal network parameters/stats) or they might be in the path to/from the phone to the public Internet.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">This looks depressingly like the old ATT HSPA stats I measured with a USB cable device.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">I'm going to look deeper.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">What 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 up on the Android Play Store.  It would be a little harder to make one for Apple - they'd probably reject it.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">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 their 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.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">I realize that lots of people at IETF seem to still believe that bufferbloat is totally unimportant, and unnecessary to fix.  However, the wireless companies are, unlike cable companies, not local monopolies.  So they might decide that competition forces them to actually fix the problem, lest their competitors do so first.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p></font>