Re: [tsvwg] feedback and thoughts L4S / SCE

Sebastian Moeller <> Mon, 30 November 2020 09:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 889863A115C for <>; Mon, 30 Nov 2020 01:53:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Btjej9dEeVyj for <>; Mon, 30 Nov 2020 01:53:24 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 470193A1155 for <>; Mon, 30 Nov 2020 01:53:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1606729998; bh=x7WgXy4ry7zx6eJMdk7NRpfr8qRon0XksxFGpyGyTI8=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=RuMgazBhJO8Dm7sgiYk4prpS5hD44czPfbQaxnLk7Zi5VlzYtYwYfmen7u1dUi413 yWUEdPgg2SKC75dB4TPtFXQCPE3AYxSJWLNjdR81I8Zq4vO6sLGDOh65b78zHkZOAd vPY2bbcV1JTNGUHeVbY5PT0N/nROkr9xphTjGXEo=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx105 []) with ESMTPSA (Nemesis) id 1MYeMt-1kg5GP1y6N-00Vjbq; Mon, 30 Nov 2020 10:53:18 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Sebastian Moeller <>
In-Reply-To: <>
Date: Mon, 30 Nov 2020 10:51:42 +0100
Cc: Mikael Abrahamsson <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <>
To: Ingemar Johansson S <>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:Q5/WuN/WTxkNK7hLiUG3ZySzuPyVnSILYh6PQKhGR4JGQrmIjKo K77oCxwQ9RLvMAI2ss9pbWd59bGWEo6oipmHgu1CsFtPspUHEKqfatufK0Lz2B5H68oQob+ eJAbyHiUO27WwoxAeHT9ZX4XdEa7oHBUjX376anCDtuXf7N+fVf/CoppA9xaHlKIsEHCfln 8CO01V/lnkzdA9LeQaYRA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:/KBhuniqqbw=:7cOmoeqmkJCcq86u9DU19o 6tKcrH+3B2FsCXuu5XSnhlhZedlaeu3Il/HrMoWnHJ2u9LY6Ja5jOz5lzZptm6oMKqPuxdKA1 3GSFBht32UfXG76JsEXEHWWVzNofw0Oz7z/td99AXmtb0QPK21dwQqD1f0M4ofp9c/HYKSCCW 5sd1/BcRY6050kQr0XOlNj5Tl0TN7Fozopw5KdpUXr1lPx0Z5kT1gHhgwiMlKEEbgPpYaigFn msOk9t3cyGIwbqmwwPZKxwPQCQu3ZpIAV1mnHf+CoyHy6TgBiPVMiL74pL4n4tcf6erpqnvrm K8E6TjuNpRcp4yl+CVDzeiOmwJjQ2Tvl8OYHx6tDJj47UhlJU6o31q8ZLOBaGIe9VWIktb4cp CcVaRNKCTrlGnY47ml/u4/osR5wxxpEjsaH6g9vrT20NkceAoh6X2NsLbGZ9/lMsW5b/+N6dH gBwD+JaLMRj5Ia74pBann8WXVYawhAMUQfP3Yk9quK/rlvxx/fKysK5ddZllOZV2OIoOR+QC2 xVgEMk3rmGiyQ26JlGv5Ab4Rk2HLlZ+f4wM/DaaHIqAmhwyHPFiWW20uRvQIAOXMfOQjmBi1b fO8JWw6G9VJCjN59MqcdzIqYxM2MYIYhGKID6mZOA8/6khu9U7Ibc7um2dup5lhMJ7ku9hoPm hqkitXRJ8M7+5JCjRq4VaLeLW4IHOERctS2WpG1t6tduAHwt3OV8tTu6ETfLvH7ajsfdna7In nM2QK+C/yb1vsuVL6JPMCZhNVP9ZoJbN3fxMtyUoeRcsBT5Kdisd3B1eLG+4v8B/eCuYH0L15 sSNXp06iGPCsmhr6o4StOGY7Dz9bTobbSphLrWVWEo46k4pLQXRLj+f7E3MfZ6ICp7jn+/KZO OzHf7XL7DzehZhKE6kjA==
Archived-At: <>
Subject: Re: [tsvwg] feedback and thoughts L4S / SCE
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 30 Nov 2020 09:53:27 -0000

Hi Ingemar,

I am not sure how your post relates to the one you seemingly replied to? 

> On Nov 30, 2020, at 10:14, Ingemar Johansson S <> wrote:
> Hi
> I am not sure what conclusions I should draw from this. 

	[SM] If you would look at what L4S actually delivers the conclusion should be that it simply is not ready, but I realize that in spite of hard supporting data your assessment ist different.

> Lossy AQMs is a non-issue as both DCTCP and Prague makes a fallback to loss
> based recovery so that is settled.

	[SM] Well, not really, both DCTCP and TCP Prague are atrocious with medium length RTTs and non-L4S AQMs (unless that AQM is flow fair), they are simply not ready for being used over the wider internet. In a sense that DCTCP is not suitable as an internet-wide protocol (without significant changes) is one of the results of the L4S experiments, as is the fact that TCP Prague does not yet? describe a complete set of required fixes (just look at TCP Pragues performance versus CUBIC in a purely drop based FIFO buffer). And Koen admitted as much when he proposed to change TCP Prague to behave like CUBIC if the RTT exceeds ~80ms. 
	I am still waiting for a demonstration of L4S robustly and reliably delivering on its promises over anything but the low hop-count short RTT paths that have been over-tested so far. 

> That leaves us with the long discussion RFC3168 AQMs. Here the discussion
> leaves me thinking that we are talking about a very limited actual
> deployment in other words too much ado about very little.

	[SM] citation needed? The challenge is that we have no reliable numbers, one way or the other. Your assessment, says more about your leaning towards L4S than about the deployed reality in the internet. 

> In addition, I get
> the impression that these limited deployments are seen as monoliths that
> cannot be modified and updated,

	[SM] So I wonder in what kind of blessed reality you seem to be living? In my experience updates for most consumer-grade networked equipment are pretty rare and often stop way before the useful live of such devices, assuming all of these can/will be updated in time is simply unrealistic. Any proposal that relies on that has the onus of convincing the reviewers why this time around this will be a successful approach. 

> which is a bit confusing too as fq_codel can
> be configured for DCTCP..

	[SM] The latter point might be true, but will fq_codel with your proposed configuration change still perform equally well with standard-compliant rfc3168 ECN flows? These are and will be for a considerable time be the dominant ECN users on the internet. 

> So, my conclusion is that we should move on to WGLC, worries about possible
> boxes on the network is something that can be quantified during the L4S
> experiment.

	[SM] Well, but then the experiment can not be "how to deploy L4S" maybe "can we deploy L4S" might be a worth while question, but it has become clear that nobody in team L4S is even willing to offer contingency plans what to do in case their hopes do not come true. How to re-claim ECT(1), what to do with deployed L4S dual-queue AQMs, what to do with endpoints that configured TCP Prague as default CC, all questions that should have be discussed in the L4S internet drafts IMHO, indicating that in addition to L4S' design and implementation not being ready, the drafts are equally half-baked (heck there isn't even an internet draft for L4S' reference CC implementation in TCP Prague at all, as far as I can see). Ready it ain't, so why rush to WGLC?


> /Ingemar
>> -----Original Message-----
>> From: tsvwg <> On Behalf Of Sebastian Moeller
>> Sent: den 28 november 2020 18:07
>> To: Mikael Abrahamsson <>
>> Cc:
>> Subject: Re: [tsvwg] feedback and thoughts L4S / SCE
>> Hi Mikael,
>> I actually wanted to stay out of tis sub thread, but...
>>> On Nov 28, 2020, at 17:24, Mikael Abrahamsson <>
>> wrote:
>>> On Sat, 28 Nov 2020, Jonathan Morton wrote:
>>>> Take a random sampling of CPE devices, and see how many of them use the
>> above - or it might be easier to count the ones that don't.  I'll wait.
>>> My ubiquiti APs come with it, but it's default turned off.
>>> It's not only important of the devices have the capability, it also
> needs to be
>> default turned on so it's actually used (considering most people don't
> change
>> config much).
>> 	[SM] ... if end-user devices have such capabilities, the big ISPs
> that in
>> all likelihood are the biggest buyers of such devices, should have little
> issues
>> adding that to their requirements list for their purchases and making sure
>> devices are configured properly, without driving up the costs unduly, no?.
>> 	The fact that that has not happened is in itself a rather clear
> indication
>> that ISPs are really not that interested in tackling latency under load
> (and why
>> should they, often unhappy users will switch to a higher/more profitable
>> speed tier in a well-intended but not very effective attempt at improving
> a
>> link's usefulness).
>> 	Now, for end-users that is a different issue, and there are quite
> some,
>> often on-line gamers interested in reducing their internet access link's
>> latency, that are actually willing to buy and configure boutique devices,
> like
>> the NetDUMA, or more down to earth and less hyped (but IMHO even more
>> capable) evenroute's iqrouter. Incidentally, both are basically software
>> distributions for relative standard existing router's from other
> manufacturers,
>> and yet people are paying a premium to get those better behaving router
> OS,
>> as latency under load performance of stock router OSes often is not
> "cutting
>> it"...
>> 	I note that L4S never reached out to those end-users actually caring
>> for low latency... instead they are trying to convince the ISP market,
> without a
>> narrative how this is going to imprive an ISP's bottom-line (the you need
> to do
>> this to not fall behind the competition, is not a positive selling point
> IMHO).
>> Best Regards
>> 	Sebastian