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 E0AA221F245 for ; Thu, 11 Sep 2014 17:31:43 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 20FD7280366; Thu, 11 Sep 2014 20:31:42 -0400 (EDT) X-Virus-Scanned: OK Received: from app30.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp4.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C9684280146; Thu, 11 Sep 2014 20:31:41 -0400 (EDT) X-Sender-Id: dpreed@reed.com Received: from app30.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.2.10); Fri, 12 Sep 2014 00:31:42 GMT Received: from reed.com (localhost.localdomain [127.0.0.1]) by app30.wa-webapps.iad3a (Postfix) with ESMTP id 99F9080059; Thu, 11 Sep 2014 20:31:40 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Thu, 11 Sep 2014 20:31:40 -0400 (EDT) Date: Thu, 11 Sep 2014 20:31:40 -0400 (EDT) From: dpreed@reed.com To: "Dave Taht" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20140911203140000000_41712" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: Message-ID: <1410481900.628723265@apps.rackspace.com> X-Mailer: webmail7.0 Cc: Wes Felter , =?utf-8?Q?Joel_Wir=C4=81mu_Pauling?= , "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Cerowrt-devel] =?utf-8?q?Fixing_bufferbloat=3A_How_about_an_open?= =?utf-8?q?_letter_to_the_web_benchmarkers=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, 12 Sep 2014 00:32:12 -0000 ------=_20140911203140000000_41712 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AI will sign. It would be better if we had an actual demonstration of ho= w to implement a speedtest improvement.=0A =0A=0A=0AOn Thursday, September = 11, 2014 12:03pm, "Dave Taht" said:=0A=0A=0A=0A> The = theme of networks being "engineered for speedtest" has been a=0A> common th= read in nearly every conversation I've had with ISPs and=0A> vendors using = every base technology out there, be it dsl, cable,=0A> ethernet, or fiber, = for the last 4 years. Perhaps, in pursuing better=0A> code, and RFCs, and t= he like, we've been going about fixing=0A> bufferbloat the wrong way.=0A> = =0A> If Verizon can petition the FCC to change the definition of=0A> broadb= and... why can't we petition speedtest to *change their test*?=0A> Switchin= g to merely reporting the 98th percentile results for ping=0A> during an up= load or download, instead of the baseline ping, would be a=0A> vast improve= ment on what happens today, and no doubt we could suggest=0A> other improve= ments.=0A> =0A> What if we could publish an open letter to the benchmark ma= kers such=0A> as speedtest, explaining how engineering for their test does = *not*=0A> make for a better internet? The press fallout from that letter, w= ould=0A> improve some user education, regardless if we could get the tests= =0A> changed or not.=0A> =0A> Who here would sign?=0A> =0A> =0A> On Wed, Se= p 10, 2014 at 2:54 PM, Joel Wir=C4=81mu Pauling=0A> wro= te:=0A> > I have been heavily involved with the UFB (Ultrafast Broadband) P= ON=0A> > deployment here in New Zealand.=0A> >=0A> > I am not sure how the = regulated environment is playing out in Canada=0A> > (I am moving there in = a month so I guess I will find out). But here=0A> > the GPON architecture i= s METH based and Layer2 only. Providers (RSP's)=0A> > are the ones responsi= ble for asking for Handoffer buffer tweaks to the=0A> > LFC(local fibre com= panies; the layer 0-2 outfits-) which have mandated=0A> > targets for Laten= cy (at most 4.5ms) accross their PON Access networks=0A> > to the Handover = port.=0A> >=0A> > Most of the time this has been to 'fix' Speedtest.net TCP= based=0A> > results to report whatever Marketed service (100/30 For exampl= e) is in=0A> > everyones favourite site speedtest.net.=0A> >=0A> > This has= meant at least for the Chorus LFC regions where they use=0A> > Alcatel-Luc= ent 7450's as the handover/aggregation switches we have=0A> > deliberately = introduced buffer bloat to please the RSP's - who=0A> > otherwise get whing= y about customers whinging about speedtest not=0A> > showing 100/30mbit. Of= course user education is 'too hard' .=0A> ________________________________= _______________=0A> Cerowrt-devel mailing list=0A> Cerowrt-devel@lists.buff= erbloat.net=0A> https://lists.bufferbloat.net/listinfo/cerowrt-devel=0A> ------=_20140911203140000000_41712 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I will sign.  It woul= d be better if we had an actual demonstration of how to implement a speedte= st improvement.

=0A

 

=0A=0A



On= Thursday, September 11, 2014 12:03pm, "Dave Taht" <dave.taht@gmail.com&= gt; said:

=0A
=0A

> The theme of networks being "engineered for speedtest" has been = a
> common thread in nearly every conversation I've had with ISPs a= nd
> vendors using every base technology out there, be it dsl, cabl= e,
> ethernet, or fiber, for the last 4 years. Perhaps, in pursuing= better
> code, and RFCs, and the like, we've been going about fixi= ng
> bufferbloat the wrong way.
>
> If Verizon can= petition the FCC to change the definition of
> broadband... why ca= n't we petition speedtest to *change their test*?
> Switching to me= rely reporting the 98th percentile results for ping
> during an upl= oad or download, instead of the baseline ping, would be a
> vast im= provement on what happens today, and no doubt we could suggest
> ot= her improvements.
>
> What if we could publish an open let= ter to the benchmark makers such
> as speedtest, explaining how eng= ineering for their test does *not*
> make for a better internet? Th= e press fallout from that letter, would
> improve some user educati= on, regardless if we could get the tests
> changed or not.
>= ;
> Who here would sign?
>
>
> On Wed, S= ep 10, 2014 at 2:54 PM, Joel Wir=C4=81mu Pauling
> <joel@aenerti= a.net> wrote:
> > I have been heavily involved with the UFB (= Ultrafast Broadband) PON
> > deployment here in New Zealand.
> >
> > I am not sure how the regulated environment is p= laying out in Canada
> > (I am moving there in a month so I gues= s I will find out). But here
> > the GPON architecture is METH b= ased and Layer2 only. Providers (RSP's)
> > are the ones respons= ible for asking for Handoffer buffer tweaks to the
> > LFC(local= fibre companies; the layer 0-2 outfits-) which have mandated
> >= ; targets for Latency (at most 4.5ms) accross their PON Access networks
> > to the Handover port.
> >
> > Most of the= time this has been to 'fix' Speedtest.net TCP based
> > results= to report whatever Marketed service (100/30 For example) is in
> &= gt; everyones favourite site speedtest.net.
> >
> > T= his has meant at least for the Chorus LFC regions where they use
> = > Alcatel-Lucent 7450's as the handover/aggregation switches we have
> > deliberately introduced buffer bloat to please the RSP's - who<= br />> > otherwise get whingy about customers whinging about speedtes= t not
> > showing 100/30mbit. Of course user education is 'too h= ard' .
> _______________________________________________
> = Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

= =0A
 ------=_20140911203140000000_41712--