Re: [tsvwg] [Ecn-sane] per-flow scheduling

"David P. Reed" <dpreed@deepplum.com> Thu, 27 June 2019 21:31 UTC

Return-Path: <dpreed@deepplum.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64346120298 for <tsvwg@ietfa.amsl.com>; Thu, 27 Jun 2019 14:31:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=g001.emailsrvr.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUhcc3zU-0yo for <tsvwg@ietfa.amsl.com>; Thu, 27 Jun 2019 14:31:03 -0700 (PDT)
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 ietfa.amsl.com (Postfix) with ESMTPS id F282F120114 for <tsvwg@ietf.org>; Thu, 27 Jun 2019 14:31:02 -0700 (PDT)
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
From: "David P. Reed" <dpreed@deepplum.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Sebastian Moeller <moeller0@gmx.de>, Jonathan Morton <chromatix99@gmail.com>, "ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.bufferbloat.net>, tsvwg IETF list <tsvwg@ietf.org>
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> <CAHx=1M4+sJBEe-wqCyuVyy=oDz7A+SG_ZxBbu_ZZDZiCHrX2uw@mail.gmail.com> <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
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/AvkDQYyDQ7rWPIkP-ohenoKaQxE>
Subject: Re: [tsvwg] [Ecn-sane] per-flow scheduling
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2019 21:31:09 -0000

It's even worse. The FCC 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 Advisory Committee and also in its Spectrum Policy Task Force, then later involved in the rather confused discussions of Network Neutrality, where again "speed" in the "up-to" sense was the sole framing of the discussion.
 
Because it was mostly lawyers and lobbyists (not network engineers), this focus on max speed as the sole measure of quality ended up with a huge distortion of the discussion, strongly encouraged by the lobbyists who love confusion.
 
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.
 
If 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.
 
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 score.
 
When I talk to people who are interested in quality of Internet service, I point them at DSL Reports' speed test.
 
That is a big win.  However, marketers of Internet access services don't compete to get good scores at DSL Reports. Even "business" providers provide crappy scores.
 
Comcast 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 there, and Comcast is the only real game in town for us, so I tried to get the 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 monetary benefit in fixing anything (going from DOCSIS 2 to DOCSIS 3.1 which had already been on the market for several years would have fixed it, probably).
 
On Thursday, June 27, 2019 4:33pm, "Brian E Carpenter" <brian.e.carpenter@gmail.com> said:



> 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; whether such behaviour shoud be
> encouraged is a different question.
> 
> I think this is encouraged by, or is even a direct result of, so called "speed
> tests" for use by consumers (such as https://www.speedtest.net/), and the way
> connectivity "speed" has been used as a marketing tool. At least where I live,
> "speed" is the main marketing tool for switching users to fibre instead of copper.
> No doubt it will be used as the main marketing tool for 5G too.
> 
> It's almost as if those marketing people don't understand queueing theory.
> 
> Brian
> 
> 
>