From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp89.iad3a.emailsrvr.com (smtp89.iad3a.emailsrvr.com [173.203.187.89]) (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 8E48621F1F3 for ; Fri, 14 Mar 2014 14:40:16 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp20.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 2A8721000D4; Fri, 14 Mar 2014 17:40:15 -0400 (EDT) X-Virus-Scanned: OK Received: from app36.wa-webapps.iad3a (relay.iad3a.rsapps.net [172.27.255.110]) by smtp20.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 12942100087; Fri, 14 Mar 2014 17:40:15 -0400 (EDT) Received: from reed.com (localhost.localdomain [127.0.0.1]) by app36.wa-webapps.iad3a (Postfix) with ESMTP id F238A380046; Fri, 14 Mar 2014 17:40:14 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Fri, 14 Mar 2014 17:40:14 -0400 (EDT) Date: Fri, 14 Mar 2014 17:40:14 -0400 (EDT) From: dpreed@reed.com To: "Rich Brown" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20140314174014000000_40452" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: Message-ID: <1394833214.989624614@apps.rackspace.com> X-Mailer: webmail7.0 Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] =?utf-8?q?Got_Bloat=3F?= X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 21:40:17 -0000 ------=_20140314174014000000_40452 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AI 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 fo= lks 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 t= o 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).=0A =0AAfter interven= tion by "friends of ATT technical management" they agreed to measure and di= scovered 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 g= ot maximum *throughput* that was all that mattered - multi-second latency w= as just not on their radar screen.=0A =0ASo, 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.=0A =0AAnd they can get peer-reviewed "surveys" from IETF that say this= is not a problem for anyone but a minuscule fraction of cranky experts.=0A= =0AReality denial is really, really good from the cellular industry. AFA= IK, even the stuff that Jim Gettys got his research buddies in ALU to demon= strate in LTE has not been fixed in shipping products or in the field.=0A = =0AOf course, they have a monopoly, so why fix anything? - just sell upgrad= es to "premium" service instead.=0A =0A=0A=0AOn Friday, March 14, 2014 4:57= pm, "Rich Brown" said:=0A=0A=0A=0A> I'm riding on= the bus to Boston. It's wifi equipped, but the=0A> connection's terribly s= low. A ping (attached) shows:=0A> =0A> - No responses for 10 seconds, then= the first ping returns. (!)=0A> - This trace gets as bad as 12 seconds, b= ut I have seen another with 20 seconds=0A> =0A> I wonder what it would take= to get the bus company to talk to their=0A> radio vendor,=0A> and get a be= tter SQM in their router and head end...=0A> =0A> Rich=0A> =0A> bash-3.2$ p= ing gstatic.com=0A> PING gstatic.com (74.125.196.120): 56 data bytes=0A> Re= quest timeout for icmp_seq 0=0A> Request timeout for icmp_seq 1=0A> Request= timeout for icmp_seq 2=0A> Request timeout for icmp_seq 3=0A> Request time= out for icmp_seq 4=0A> Request timeout for icmp_seq 5=0A> Request timeout f= or icmp_seq 6=0A> Request timeout for icmp_seq 7=0A> Request timeout for ic= mp_seq 8=0A> Request timeout for icmp_seq 9=0A> Request timeout for icmp_se= q 10=0A> 64 bytes from 74.125.196.120: icmp_seq=3D0 ttl=3D35 time=3D11080.9= 51 ms=0A> 64 bytes from 74.125.196.120: icmp_seq=3D1 ttl=3D35 time=3D10860.= 209 ms=0A> Request timeout for icmp_seq 13=0A> 64 bytes from 74.125.196.120= : icmp_seq=3D2 ttl=3D35 time=3D12432.495 ms=0A> 64 bytes from 74.125.196.12= 0: icmp_seq=3D3 ttl=3D35 time=3D11878.852 ms=0A> 64 bytes from 74.125.196.1= 20: icmp_seq=3D4 ttl=3D35 time=3D11111.612 ms=0A> 64 bytes from 74.125.196.= 120: icmp_seq=3D5 ttl=3D35 time=3D11170.454 ms=0A> 64 bytes from 74.125.196= .120: icmp_seq=3D6 ttl=3D35 time=3D10774.446 ms=0A> 64 bytes from 74.125.19= 6.120: icmp_seq=3D7 ttl=3D35 time=3D9991.265 ms=0A> 64 bytes from 74.125.19= 6.120: icmp_seq=3D8 ttl=3D35 time=3D9068.379 ms=0A> 64 bytes from 74.125.19= 6.120: icmp_seq=3D9 ttl=3D35 time=3D8162.352 ms=0A> 64 bytes from 74.125.19= 6.120: icmp_seq=3D10 ttl=3D35 time=3D7321.143 ms=0A> 64 bytes from 74.125.1= 96.120: icmp_seq=3D11 ttl=3D35 time=3D6553.093 ms=0A> 64 bytes from 74.125.= 196.120: icmp_seq=3D12 ttl=3D35 time=3D6205.100 ms=0A> 64 bytes from 74.125= .196.120: icmp_seq=3D13 ttl=3D35 time=3D5384.352 ms=0A> 64 bytes from 74.12= 5.196.120: icmp_seq=3D14 ttl=3D35 time=3D4903.169 ms=0A> 64 bytes from 74.1= 25.196.120: icmp_seq=3D15 ttl=3D35 time=3D4821.944 ms=0A> 64 bytes from 74.= 125.196.120: icmp_seq=3D16 ttl=3D35 time=3D4438.738 ms=0A> 64 bytes from 74= .125.196.120: icmp_seq=3D17 ttl=3D35 time=3D4239.312 ms=0A> 64 bytes from 7= 4.125.196.120: icmp_seq=3D18 ttl=3D35 time=3D5573.525 ms=0A> 64 bytes from = 74.125.196.120: icmp_seq=3D19 ttl=3D35 time=3D5023.965 ms=0A> 64 bytes from= 74.125.196.120: icmp_seq=3D20 ttl=3D35 time=3D4994.414 ms=0A> 64 bytes fro= m 74.125.196.120: icmp_seq=3D21 ttl=3D35 time=3D4679.299 ms=0A> 64 bytes fr= om 74.125.196.120: icmp_seq=3D22 ttl=3D35 time=3D5013.662 ms=0A> 64 bytes f= rom 74.125.196.120: icmp_seq=3D23 ttl=3D35 time=3D5557.759 ms=0A> ^C=0A> --= - gstatic.com ping statistics ---=0A> 32 packets transmitted, 24 packets re= ceived, 25.0% packet loss=0A> round-trip min/avg/max/stddev =3D 4239.312/75= 51.687/12432.495/2805.706 ms=0A> __________________________________________= _____=0A> Cerowrt-devel mailing list=0A> Cerowrt-devel@lists.bufferbloat.ne= t=0A> https://lists.bufferbloat.net/listinfo/cerowrt-devel=0A> ------=_20140314174014000000_40452 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I can tell= you that when I originally spoke to ATT about their "4G" HSPA+ network's b= uffer bloat (which was before it had that name and when the folks in the IE= TF 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).

=0A

 

=0A

After intervention by "= friends of ATT technical management" they agreed to measure and discovered = that my measurements were accurate.  They apparently went back to thei= r vendor, who apparently claimed that I could not possibly be right and tha= t ATT could not possibly be right, either, making some comment or other abo= ut "channel scheduling" being the problem and arguing that since they got m= aximum *throughput* that was all that mattered - multi-second latency was j= ust not on their radar screen.

=0A

 = ;

=0A

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.

=0A

 

=0A

And they can get peer-reviewed "surveys" from IETF that= say this is not a problem for anyone but a minuscule fraction of cranky ex= perts.

=0A

 

=0A

Reality denial is really, really good from the cellular in= dustry.   AFAIK, even the stuff that Jim Gettys got his research buddi= es in ALU to demonstrate in LTE has not been fixed in shipping products or = in the field.

=0A

 

=0A

Of course, they have a monopoly, so why fix anythi= ng? - just sell upgrades to "premium" service instead.

=0A

 

=0A=0A



On Fri= day, March 14, 2014 4:57pm, "Rich Brown" <richb.hanover@gmail.com> sa= id:

=0A
=0A

> I'm riding on the bus to Boston. It's wifi equipped, b= ut 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 an= other with 20 seconds
>
> I wonder what it would take to g= et the bus company to talk to their
> radio vendor,
> and g= et a better SQM in their router and head end...
>
> Rich>
> bash-3.2$ ping gstatic.com
> PING gstatic.com (= 74.125.196.120): 56 data bytes
> Request timeout for icmp_seq 0
> Request timeout for icmp_seq 1
> Request timeout for icmp_se= q 2
> Request timeout for icmp_seq 3
> Request timeout for = icmp_seq 4
> Request timeout for icmp_seq 5
> Request timeo= ut for icmp_seq 6
> Request timeout for icmp_seq 7
> Reques= t timeout for icmp_seq 8
> Request timeout for icmp_seq 9
>= Request timeout for icmp_seq 10
> 64 bytes from 74.125.196.120: ic= mp_seq=3D0 ttl=3D35 time=3D11080.951 ms
> 64 bytes from 74.125.196.= 120: icmp_seq=3D1 ttl=3D35 time=3D10860.209 ms
> Request timeout fo= r icmp_seq 13
> 64 bytes from 74.125.196.120: icmp_seq=3D2 ttl=3D35= time=3D12432.495 ms
> 64 bytes from 74.125.196.120: icmp_seq=3D3 t= tl=3D35 time=3D11878.852 ms
> 64 bytes from 74.125.196.120: icmp_se= q=3D4 ttl=3D35 time=3D11111.612 ms
> 64 bytes from 74.125.196.120: = icmp_seq=3D5 ttl=3D35 time=3D11170.454 ms
> 64 bytes from 74.125.19= 6.120: icmp_seq=3D6 ttl=3D35 time=3D10774.446 ms
> 64 bytes from 74= .125.196.120: icmp_seq=3D7 ttl=3D35 time=3D9991.265 ms
> 64 bytes f= rom 74.125.196.120: icmp_seq=3D8 ttl=3D35 time=3D9068.379 ms
> 64 b= ytes from 74.125.196.120: icmp_seq=3D9 ttl=3D35 time=3D8162.352 ms
>= ; 64 bytes from 74.125.196.120: icmp_seq=3D10 ttl=3D35 time=3D7321.143 ms> 64 bytes from 74.125.196.120: icmp_seq=3D11 ttl=3D35 time=3D6553.0= 93 ms
> 64 bytes from 74.125.196.120: icmp_seq=3D12 ttl=3D35 time= =3D6205.100 ms
> 64 bytes from 74.125.196.120: icmp_seq=3D13 ttl=3D= 35 time=3D5384.352 ms
> 64 bytes from 74.125.196.120: icmp_seq=3D14= ttl=3D35 time=3D4903.169 ms
> 64 bytes from 74.125.196.120: icmp_s= eq=3D15 ttl=3D35 time=3D4821.944 ms
> 64 bytes from 74.125.196.120:= icmp_seq=3D16 ttl=3D35 time=3D4438.738 ms
> 64 bytes from 74.125.1= 96.120: icmp_seq=3D17 ttl=3D35 time=3D4239.312 ms
> 64 bytes from 7= 4.125.196.120: icmp_seq=3D18 ttl=3D35 time=3D5573.525 ms
> 64 bytes= from 74.125.196.120: icmp_seq=3D19 ttl=3D35 time=3D5023.965 ms
> 6= 4 bytes from 74.125.196.120: icmp_seq=3D20 ttl=3D35 time=3D4994.414 ms
> 64 bytes from 74.125.196.120: icmp_seq=3D21 ttl=3D35 time=3D4679.299 = ms
> 64 bytes from 74.125.196.120: icmp_seq=3D22 ttl=3D35 time=3D50= 13.662 ms
> 64 bytes from 74.125.196.120: icmp_seq=3D23 ttl=3D35 ti= me=3D5557.759 ms
> ^C
> --- gstatic.com ping statistics ---=
> 32 packets transmitted, 24 packets received, 25.0% packet loss> round-trip min/avg/max/stddev =3D 4239.312/7551.687/12432.495/2805= .706 ms
> _______________________________________________
>= Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

= =0A
 ------=_20140314174014000000_40452--