[Cerowrt-devel] Got Bloat?

dpreed at reed.com dpreed at reed.com
Fri Mar 14 17:40:14 EDT 2014

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).
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.
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.
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.
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.
Of course, they have a monopoly, so why fix anything? - just sell upgrades to "premium" service instead.

On Friday, March 14, 2014 4:57pm, "Rich Brown" <richb.hanover at gmail.com> said:

> I'm riding on the bus to Boston. It's wifi equipped, but the
> connection's terribly slow.  A ping (attached) shows:
> - No responses for 10 seconds, then the first ping returns.  (!)
> - This trace gets as bad as 12 seconds, but I have seen another with 20 seconds
> I wonder what it would take to get the bus company to talk to their
> radio vendor,
> and get a better SQM in their router and head end...
> Rich
> bash-3.2$ ping gstatic.com
> PING gstatic.com ( 56 data bytes
> Request timeout for icmp_seq 0
> Request timeout for icmp_seq 1
> Request timeout for icmp_seq 2
> Request timeout for icmp_seq 3
> Request timeout for icmp_seq 4
> Request timeout for icmp_seq 5
> Request timeout for icmp_seq 6
> Request timeout for icmp_seq 7
> Request timeout for icmp_seq 8
> Request timeout for icmp_seq 9
> Request timeout for icmp_seq 10
> 64 bytes from icmp_seq=0 ttl=35 time=11080.951 ms
> 64 bytes from icmp_seq=1 ttl=35 time=10860.209 ms
> Request timeout for icmp_seq 13
> 64 bytes from icmp_seq=2 ttl=35 time=12432.495 ms
> 64 bytes from icmp_seq=3 ttl=35 time=11878.852 ms
> 64 bytes from icmp_seq=4 ttl=35 time=11111.612 ms
> 64 bytes from icmp_seq=5 ttl=35 time=11170.454 ms
> 64 bytes from icmp_seq=6 ttl=35 time=10774.446 ms
> 64 bytes from icmp_seq=7 ttl=35 time=9991.265 ms
> 64 bytes from icmp_seq=8 ttl=35 time=9068.379 ms
> 64 bytes from icmp_seq=9 ttl=35 time=8162.352 ms
> 64 bytes from icmp_seq=10 ttl=35 time=7321.143 ms
> 64 bytes from icmp_seq=11 ttl=35 time=6553.093 ms
> 64 bytes from icmp_seq=12 ttl=35 time=6205.100 ms
> 64 bytes from icmp_seq=13 ttl=35 time=5384.352 ms
> 64 bytes from icmp_seq=14 ttl=35 time=4903.169 ms
> 64 bytes from icmp_seq=15 ttl=35 time=4821.944 ms
> 64 bytes from icmp_seq=16 ttl=35 time=4438.738 ms
> 64 bytes from icmp_seq=17 ttl=35 time=4239.312 ms
> 64 bytes from icmp_seq=18 ttl=35 time=5573.525 ms
> 64 bytes from icmp_seq=19 ttl=35 time=5023.965 ms
> 64 bytes from icmp_seq=20 ttl=35 time=4994.414 ms
> 64 bytes from icmp_seq=21 ttl=35 time=4679.299 ms
> 64 bytes from icmp_seq=22 ttl=35 time=5013.662 ms
> 64 bytes from icmp_seq=23 ttl=35 time=5557.759 ms
> ^C
> --- gstatic.com ping statistics ---
> 32 packets transmitted, 24 packets received, 25.0% packet loss
> round-trip min/avg/max/stddev = 4239.312/7551.687/12432.495/2805.706 ms
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140314/4947b6ac/attachment-0002.html>

More information about the Cerowrt-devel mailing list