Re: [tcpm] [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S

Mikael Abrahamsson <swmike@swm.pp.se> Tue, 06 August 2019 09:50 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC9712014F; Tue, 6 Aug 2019 02:50:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 8p0L-Y3UKegM; Tue, 6 Aug 2019 02:50:00 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBB9312006F; Tue, 6 Aug 2019 02:49:59 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0630CB4; Tue, 6 Aug 2019 11:49:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1565084995; bh=y0fuyQrLNRv9gf9yaBA7qN5XkZ6xUEBmw/SvXDZlp7M=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=T1EUT0ZMwE5wW0lw0rhkKWBsczEpu2nN8T2S+kFJ3lKzUeUhwNg4YrBFQnK5gcrMP v5xkyrP+GXZ724sTn8JF+6a3NP7VNrtI8Re/Cb8zv+aDUIGjAWZB82T529ks/cHBUc qdCJcfW1TbJLE3hqGLUP9skjAf6y8Cd7WDVyZCHQ=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0259CB1; Tue, 6 Aug 2019 11:49:55 +0200 (CEST)
Date: Tue, 06 Aug 2019 11:49:54 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Sebastian Moeller <moeller0@gmx.de>
cc: Ruediger.Geib@telekom.de, tcpm@ietf.org, ECN-Sane <ecn-sane@lists.bufferbloat.net>, tsvwg IETF list <tsvwg@ietf.org>
In-Reply-To: <3AB4DBF2-C0B3-45EE-8E82-E2D337EA346E@gmx.de>
Message-ID: <alpine.DEB.2.20.1908061122560.7741@uplift.swm.pp.se>
References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> <E54BA49C-0790-48B4-82BB-4C0F3FE3FB20@gmail.com> <FRXPR01MB0710085AE4AEFA896819AFA69CD90@FRXPR01MB0710.DEUPRD01.PROD.OUTLOOK.DE> <0E44351D-2520-45AD-A10A-8E2FFE186722@gmx.de> <LEXPR01MB0463C090812BEA6DAB566A1E9CDA0@LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE> <20C58AE1-CAC4-480F-8E80-1F5A09ED53EA@gmx.de> <LEXPR01MB046367DE6489CE0F20E4B2359CDA0@LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE> <3AB4DBF2-C0B3-45EE-8E82-E2D337EA346E@gmx.de>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/h1BP-ZHurG6vQCruZWwJSiYpliU>
Subject: Re: [tcpm] [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Aug 2019 09:50:03 -0000

On Mon, 5 Aug 2019, Sebastian Moeller wrote:

> 	That is a good question, as far as I see it, ISPs in Germany still 
> seem to leverage access-rates as their main attraction (giga this and 
> giga that), even though as you note higher rates have diminishing 
> returns for most use-cases.

It's great marketing. Same way as car manufacturers make prototypes and 
high end cars ("halo cars") to sell their high-volume mainstream cars. 
It's brand building. So don't judge the customer interest for actual 
product sales, by the marketing you see. They might not correlate 
directly.

There is also one more thing that people nowadays do that wasn't directly 
on your list. Software downloads. Either on game console or on a PC, these 
downloads can easily be in tens of gigabytes. I personally have a 250/100 
connection at home, and download of a large modern game can take 30-60 
minutes, because it's 50 GB. I do not know what congestion avoidance 
algorithms are used, but it seems to me that at least some of these 
software download services do not actually create congestion. They do very 
slow ramp-ups and from what I can see they typically keep the utilisation 
of my Internet connection below congestion (as in perhaps averaging at 80% 
of capacity).

Personally I frequently see several potential congestion points between 
user device and what it's communicating with.

There is the ISP-CDN or ISP-ISP interconnect point.
There might be congestion on the core-core links.
There is the uplink to the BNG or whatever.
There is the user-unique shaper
There is the L2 aggregation network (DOCSIS/*PON/ETTH)
There is the in-house wifi network.

So even if the ISP does a great job, we might have the user-unique shaper 
and the wifi both congesting and the wifi might be slower than the 
user-access link. This is the case in my home sometimes. Even with a great 
wifi setup (multiple 5GHz APs) I frequently get congestion there resulting 
in lower speeds than my 250 megabit/s Internet access speed. So this means 
traffic might encounter half of the time my 250 megabit/s ISP shaper as 
the bottleneck, then sporadically it encounters my wifi lowering the speed 
even more, and then returning to my ISP shaper being the slowest point.

So I think your suggestion of what we should test is useful.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se