From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp98.iad3a.emailsrvr.com (smtp98.iad3a.emailsrvr.com [173.203.187.98]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E82663B29E for ; Thu, 27 Jun 2019 17:31:01 -0400 (EDT) Received: from smtp37.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp37.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id B27B15CBB; Thu, 27 Jun 2019 17:31:01 -0400 (EDT) X-SMTPDoctor-Processed: csmtpprox beta DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=g001.emailsrvr.com; s=20190322-9u7zjiwi; t=1561671061; bh=JnWivpllSYxY/9VpGN8erHz3iaffTEZLF9XLqjx3ldI=; h=Date:Subject:From:To:From; b=Te62upYNE7h0s7jTSwQ2Yo/TO5HZFINz40j/s5KzX0Eg2ha7Zq32oNvaDOS/gFlc5 vk514t6Fhm1mHHmbxPkadITGhG3fGdDMZiQkiupVtbm/kW2bdv0u6cLaHovJDC0oTi t00RNrzJ272rbWNpfurKCDxCKO9gg7Q/I2GNX1ic= Received: from app3.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp37.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 7DC995A44; Thu, 27 Jun 2019 17:31:01 -0400 (EDT) X-Sender-Id: dpreed@deepplum.com Received: from app3.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Thu, 27 Jun 2019 17:31:01 -0400 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app3.wa-webapps.iad3a (Postfix) with ESMTP id 689F5A0042; Thu, 27 Jun 2019 17:31:01 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Thu, 27 Jun 2019 17:31:01 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Thu, 27 Jun 2019 17:31:01 -0400 (EDT) From: "David P. Reed" To: "Brian E Carpenter" Cc: "Sebastian Moeller" , "Jonathan Morton" , "ecn-sane@lists.bufferbloat.net" , "tsvwg IETF list" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20190627173101000000_34645" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <2382048d-25de-df7e-f787-8ab0d606d3dc@gmail.com> References: <350f8dd5-65d4-d2f3-4d65-784c0379f58c@bobbriscoe.net> <46D1ABD8-715D-44D2-B7A0-12FE2A9263FE@gmx.de> <835b1fb3-e8d5-c58c-e2f8-03d2b886af38@gmail.com> <1561233009.95886420@apps.rackspace.com> <71EF351D-AFBF-4C92-B6B9-7FD695B68815@gmail.com> <1561241377.4026977@apps.rackspace.com> <4E863FC5-D30E-4F76-BDF7-6A787958C628@gmx.de> <1561566706.778820831@apps.rackspace.com> <9A6E126A-43A3-4BD8-A3AC-507FF9095470@gmx.de> <2382048d-25de-df7e-f787-8ab0d606d3dc@gmail.com> Message-ID: <1561671061.42671176@apps.rackspace.com> X-Mailer: webmail/16.4.5-RC Subject: Re: [Ecn-sane] [tsvwg] per-flow scheduling X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 21:31:02 -0000 ------=_20190627173101000000_34645 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AIt's even worse. The FCC got focused on max speeds back in the day as it= s only way to think about Internet Access service. And I was serving on the= FCC Technological Advisory Committee and also in its Spectrum Policy Task = Force, then later involved in the rather confused discussions of Network Ne= utrality, where again "speed" in the "up-to" sense was the sole framing of = the discussion.=0A =0ABecause it was mostly lawyers and lobbyists (not netw= ork engineers), this focus on max speed as the sole measure of quality ende= d up with a huge distortion of the discussion, strongly encouraged by the l= obbyists who love confusion.=0A =0AThat said, max speed plays a role at all= time scales in minimizing response time, but queuing delay has no constitu= ency, even though its impact is FAR worse in real situations.=0A =0AIf the = FCC and regulators (or even the DoD communications management layers) ever= start talking about queueing delay in shared network services, I will die = of shock.=0A =0ABut we did have one HUGE temporary success. The speed test = at DSL Reports measures lag under load, and calls it bufferbloat, and gives= a reasonably scaled score.=0A =0AWhen I talk to people who are interested = in quality of Internet service, I point them at DSL Reports' speed test.=0A= =0AThat is a big win. However, marketers of Internet access services don'= t compete to get good scores at DSL Reports. Even "business" providers prov= ide crappy scores.=0A =0AComcast Business in the South Bay does very poorly= on bufferbloat for its high speed business services, for example. This is = based on my measurements at my company. I know some very high executives t= here, and Comcast is the only real game in town for us, so I tried to get t= he folks in Philadelphia to talk to the local managers. Turns out the local= managers just refused to listen to the headquarters execs. They saw no mon= etary benefit in fixing anything (going from DOCSIS 2 to DOCSIS 3.1 which h= ad already been on the market for several years would have fixed it, probab= ly).=0A =0AOn Thursday, June 27, 2019 4:33pm, "Brian E Carpenter" said:=0A=0A=0A=0A> On 27-Jun-19 19:49, Sebastian Moell= er wrote:=0A> ...=0A> > a considerable fraction of home-users seem obsessed= in maxing out their=0A> access links and compare achievable rates; whether= such behaviour shoud be=0A> encouraged is a different question.=0A> =0A> I= think this is encouraged by, or is even a direct result of, so called "spe= ed=0A> tests" for use by consumers (such as https://www.speedtest.net/), an= d the way=0A> connectivity "speed" has been used as a marketing tool. At le= ast where I live,=0A> "speed" is the main marketing tool for switching user= s to fibre instead of copper.=0A> No doubt it will be used as the main mark= eting tool for 5G too.=0A> =0A> It's almost as if those marketing people do= n't understand queueing theory.=0A> =0A> Brian=0A> =0A> =0A> ------=_20190627173101000000_34645 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

It's even worse. The F= CC got focused on max speeds back in the day as its only way to think about= Internet Access service. And I was serving on the FCC Technological Adviso= ry Committee and also in its Spectrum Policy Task Force, then later involve= d in the rather confused discussions of Network Neutrality, where again "sp= eed" in the "up-to" sense was the sole framing of the discussion.

=0A

 

=0A

Because it was mostly l= awyers and lobbyists (not network engineers), this focus on max speed as th= e sole measure of quality ended up with a huge distortion of the discussion= , strongly encouraged by the lobbyists who love confusion.

=0A

 

=0A

That said, max speed plays a= role at all time scales in minimizing response time, but queuing delay has= no constituency, even though its impact is FAR worse in real situations.=0A

 

=0A

If the FCC and = regulators (or even the DoD communications management layers)  ever st= art talking about queueing delay in shared network services, I will die of = shock.

=0A

 

=0A

But we = did have one HUGE temporary success. The speed test at DSL Reports measures= lag under load, and calls it bufferbloat, and gives a reasonably scaled sc= ore.

=0A

 

=0A

When I ta= lk to people who are interested in quality of Internet service, I point the= m at DSL Reports' speed test.

=0A

 

=0A

That is a big win.  However, marketers of Internet acc= ess services don't compete to get good scores at DSL Reports. Even "busines= s" providers provide crappy scores.

=0A

 

= =0A

Comcast Business in the South Bay does very poorly = on bufferbloat for its high speed business services, for example. This is b= ased on my measurements at my company.  I know some very high executiv= es there, and Comcast is the only real game in town for us, so I tried to g= et the folks in Philadelphia to talk to the local managers. Turns out the l= ocal managers just refused to listen to the headquarters execs. They saw no= monetary benefit in fixing anything (going from DOCSIS 2 to DOCSIS 3.1 whi= ch had already been on the market for several years would have fixed it, pr= obably).

=0A

 

=0A

On Th= ursday, June 27, 2019 4:33pm, "Brian E Carpenter" <brian.e.carpenter@gma= il.com> said:

=0A
=0A

> On 27-Jun-19 19:49, Sebastian Moeller wrote:
>= ; ...
> > a considerable fraction of home-users seem obsessed in= maxing out their
> access links and compare achievable rates; whet= her such behaviour shoud be
> encouraged is a different question.>
> I think this is encouraged by, or is even a direct resu= lt of, so called "speed
> tests" for use by consumers (such as http= s://www.speedtest.net/), and the way
> connectivity "speed" has bee= n used as a marketing tool. At least where I live,
> "speed" is the= main marketing tool for switching users to fibre instead of copper.
&= gt; No doubt it will be used as the main marketing tool for 5G too.
&g= t;
> It's almost as if those marketing people don't understand que= ueing theory.
>
> Brian
>
>
> =0A

 ------=_20190627173101000000_34645--