<font face="arial" size="2"><p style="margin:0;padding:0;">I can tell you that when I originally spoke to ATT about their "4G" HSPA+ network's buffer bloat (which was before it had that name and when the folks in the IETF said I must have been incompetently measuring the system), ATT's Sr. VP of network operations and his chief technical person refused to even try to repeat my measurements (which I had done in 5 cities and on a Boston area commuter-rail that got service from ATT).</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">After intervention by "friends of ATT technical management" they agreed to measure and discovered that my measurements were accurate. They apparently went back to their vendor, who apparently claimed that I could not possibly be right and that ATT could not possibly be right, either, making some comment or other about "channel scheduling" being the problem and arguing that since they got maximum *throughput* that was all that mattered - multi-second latency was just not on their radar screen.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">So, I'm sure that it won't be easy to talk to the access providers. They don't care, because they don't have to.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">And they can get peer-reviewed "surveys" from IETF that say this is not a problem for anyone but a minuscule fraction of cranky experts.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">Reality denial is really, really good from the cellular industry. AFAIK, even the stuff that Jim Gettys got his research buddies in ALU to demonstrate in LTE has not been fixed in shipping products or in the field.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">Of course, they have a monopoly, so why fix anything? - just sell upgrades to "premium" service instead.</p>
<p style="margin:0;padding:0;"> </p>
<!--WM_COMPOSE_SIGNATURE_START--><!--WM_COMPOSE_SIGNATURE_END-->
<p style="margin:0;padding:0;"><br /><br />On Friday, March 14, 2014 4:57pm, "Rich Brown" <richb.hanover@gmail.com> said:<br /><br /></p>
<div id="SafeStyles1394832634">
<p style="margin:0;padding:0;">> I'm riding on the bus to Boston. It's wifi equipped, but the<br />> connection's terribly slow. A ping (attached) shows:<br />> <br />> - No responses for 10 seconds, then the first ping returns. (!)<br />> - This trace gets as bad as 12 seconds, but I have seen another with 20 seconds<br />> <br />> I wonder what it would take to get the bus company to talk to their<br />> radio vendor,<br />> and get a better SQM in their router and head end...<br />> <br />> Rich<br />> <br />> bash-3.2$ ping gstatic.com<br />> PING gstatic.com (74.125.196.120): 56 data bytes<br />> Request timeout for icmp_seq 0<br />> Request timeout for icmp_seq 1<br />> Request timeout for icmp_seq 2<br />> Request timeout for icmp_seq 3<br />> Request timeout for icmp_seq 4<br />> Request timeout for icmp_seq 5<br />> Request timeout for icmp_seq 6<br />> Request timeout for icmp_seq 7<br />> Request timeout for icmp_seq 8<br />> Request timeout for icmp_seq 9<br />> Request timeout for icmp_seq 10<br />> 64 bytes from 74.125.196.120: icmp_seq=0 ttl=35 time=11080.951 ms<br />> 64 bytes from 74.125.196.120: icmp_seq=1 ttl=35 time=10860.209 ms<br />> Request timeout for icmp_seq 13<br />> 64 bytes from 74.125.196.120: icmp_seq=2 ttl=35 time=12432.495 ms<br />> 64 bytes from 74.125.196.120: icmp_seq=3 ttl=35 time=11878.852 ms<br />> 64 bytes from 74.125.196.120: icmp_seq=4 ttl=35 time=11111.612 ms<br />> 64 bytes from 74.125.196.120: icmp_seq=5 ttl=35 time=11170.454 ms<br />> 64 bytes from 74.125.196.120: icmp_seq=6 ttl=35 time=10774.446 ms<br />> 64 bytes from 74.125.196.120: icmp_seq=7 ttl=35 time=9991.265 ms<br />> 64 bytes from 74.125.196.120: icmp_seq=8 ttl=35 time=9068.379 ms<br />> 64 bytes from 74.125.196.120: icmp_seq=9 ttl=35 time=8162.352 ms<br />> 64 bytes from 74.125.196.120: icmp_seq=10 ttl=35 time=7321.143 ms<br />> 64 bytes from 74.125.196.120: icmp_seq=11 ttl=35 time=6553.093 ms<br />> 64 bytes from 74.125.196.120: icmp_seq=12 ttl=35 time=6205.100 ms<br />> 64 bytes from 74.125.196.120: icmp_seq=13 ttl=35 time=5384.352 ms<br />> 64 bytes from 74.125.196.120: icmp_seq=14 ttl=35 time=4903.169 ms<br />> 64 bytes from 74.125.196.120: icmp_seq=15 ttl=35 time=4821.944 ms<br />> 64 bytes from 74.125.196.120: icmp_seq=16 ttl=35 time=4438.738 ms<br />> 64 bytes from 74.125.196.120: icmp_seq=17 ttl=35 time=4239.312 ms<br />> 64 bytes from 74.125.196.120: icmp_seq=18 ttl=35 time=5573.525 ms<br />> 64 bytes from 74.125.196.120: icmp_seq=19 ttl=35 time=5023.965 ms<br />> 64 bytes from 74.125.196.120: icmp_seq=20 ttl=35 time=4994.414 ms<br />> 64 bytes from 74.125.196.120: icmp_seq=21 ttl=35 time=4679.299 ms<br />> 64 bytes from 74.125.196.120: icmp_seq=22 ttl=35 time=5013.662 ms<br />> 64 bytes from 74.125.196.120: icmp_seq=23 ttl=35 time=5557.759 ms<br />> ^C<br />> --- gstatic.com ping statistics ---<br />> 32 packets transmitted, 24 packets received, 25.0% packet loss<br />> round-trip min/avg/max/stddev = 4239.312/7551.687/12432.495/2805.706 ms<br />> _______________________________________________<br />> Cerowrt-devel mailing list<br />> Cerowrt-devel@lists.bufferbloat.net<br />> https://lists.bufferbloat.net/listinfo/cerowrt-devel<br />></p>
</div></font>