Re: [tsvwg] ECT(1): Plan for Vancouver

Sebastian Moeller <> Sun, 08 March 2020 11:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A1C223A0043 for <>; Sun, 8 Mar 2020 04:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Status: No, score=-1.648 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, 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 UV9tZPTjpY6z for <>; Sun, 8 Mar 2020 04:53:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5A3D63A003B for <>; Sun, 8 Mar 2020 04:53:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1583668418; bh=+w/9WA4tVQyK5F1Xq8cLaVYp6VvvBngxsM/41KwO5sw=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=kGc3LSC+JFsOihc6vUXzW8GBTo2bxofTS/MxfxZdMkNGUF07N7t9BkZMlPMDgZ8uK ODoF9M7okL04eGfgVbTdLlmw7jPfnwta6dK9XaDC6EgtMzVGiItH0Gbg1z2tHhw+xI 3fCHRSSpx5ujs5nb2pixz5ySaj4SoebkJhAWPEpc=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx105 []) with ESMTPSA (Nemesis) id 1MiJZO-1jnnh13FMU-00fPJ6; Sun, 08 Mar 2020 12:53:37 +0100
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <>
In-Reply-To: <>
Date: Sun, 08 Mar 2020 12:53:34 +0100
Cc: Jonathan Morton <>, Ingemar Johansson S <>, Ingemar Johansson S <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Greg White <>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:91s35RuVj5v2v4OCR2A0pyGmC7YW8vB616k1km1iv7UgnZloO22 MVDJoxOkgPV7vNRNPwq8spizbcNo/f+lLQY6xFoH8jiZnXn+pkTyBC83vniWL7niTdhoytO 3FUGP5Y+bQrC4lE1Sw7igeqVqGr6u8xaU8DJIO38VMaK9hvqjvDQM5M88K5JGfTvUI/TtsE +SMpKXpM678Md18zVlT+A==
X-UI-Out-Filterresults: notjunk:1;V03:K0:R3DEHD0Jic8=:+tXXVKPcCpKrOsVqN6UTE0 eVfFcyFx/2uZcBEsUTryRtw368AaDQ8oxiwfzGLVMBQrlobWrMHl7+Uz1F5m+OnXKKAImPfBc oZHtvh2syuSUN9SSzw7nKvbchAjnhnhgB0nCg+lh8vVbc5YT+R3znJAvvvItf6KbPUlw6W75z 9kzpuE/dlB30d25m7MW8Y/czRYzqmvRHdTUGiMrmx0JrG++lTGKn4jk4/GGshTq7jlmKPraS5 k6NmQxfZgKlw20R17afsU1qJWb386IHDOBh8CkR2jXCabUMBeujtuQiHt61VP1YqNWcgaB/TA A2vjKZotdHew7CnSZEE8oviU7dW25Q2bHGZqVxmy7SFHXJNgseCj2KdGz5pb4wCgKNiNGMBCr LQONZOPePFN8mrX2NnMg+tjVUXVZh13aLneL1gO0Qp0re312JRj8PLr+BB1QZIqxZ/zJQ/Kvx YM9xeZOr//lKOhCRXZv7f5foNgDpj8m6Vgqg9PxbfjgSniXOGOdd4QJJPiP4zliqPYxSNyL8C l5wjEBhdihA84xIci4bYUP9QX7CA1CY9Th8dn7oFCRlgNCoQN2KsRbDsXsGWASQ0j2gQhz9Js Y21Q+RASwSKsR/zRK8oBxQRonOi8lTqwxaXwHrOiN8aIGlRc2251f1Y+p2Yy2iNjeL1yKVQnG eLFT/RCP85XzZSmr6ppDxEdS27g+G0zrnZl/RiD0fSMBnuQfpj8JJXQYwm9jceVqPbkSYSoEr kCERiYlQnT6uS1nS86lncJpEFazo+73qVeDQvG4DWB4pzy4KPOZE36NByEoNecbxw/mftGiRH B/D0Th9EFGOor4QUnJggZgC0kcYuj+pnaxzyh5EK8tcSuyypx7s11oHx6MlFxcb99/dHxt4zE g/ok7hCwfKAV431pDcmVFttohqGjhXCXP7W/Snx9brtmgNIuVkPVI5J4NmPvJlu5+RqzbjoZ6 GV3otjt2vOf6u4F4Rlw79aqtWzKAS1iDW9o18FHBgCP/P200HmP6S08lsX70K/wyjeTI+u888 6P7PmbXX+3R6Z7SlaEWKvHPf70Lw2GGQeJH94MZrkqsjI6+2bHEvlm7sVPGUWOgVSyPGnTBYk MShabq0YSAGD8q/QtK4mWh6lPRYRcolIYJZSM7EIbkewuYVK54eoNOn3hkdvtlWKHXWREl2FB nd7VVTwW7xtNTQJ0+mqLKxHdBLdU4JQ81DCEuPCEawA4vKN3peGuDauDJvJRo+iTAX/tN9WRZ Oo8MjEfn1AhsWv4xb
Archived-At: <>
Subject: Re: [tsvwg] ECT(1): Plan for Vancouver
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: Sun, 08 Mar 2020 11:53:51 -0000

Hi Greg,

I find your description to be slightly off as well...

more below in-line

> On Mar 8, 2020, at 08:35, Greg White <> wrote:
> On 3/5/20, 3:47 AM, "tsvwg on behalf of Jonathan Morton" < on behalf of> wrote:
> [snip]
>    In that sense, even if a precise threshold for unfairness cannot be agreed upon, there is clearly a qualitative difference between a system which imposes a 15-fold reduction of available throughput on existing traffic, versus one which accepts a 2-fold reduction of throughput to itself, when deployed in a shared environment without FQ.  I think when shown that way, consensus that one is acceptable but the other is not would be straightforward to achieve.
>     - Jonathan Morton
> [GW] I hope that there isn't anyone reading this mailing list who believes that the above is an accurate characterization of the debate between L4S and SCE.   To provide some balance to the above, here is (in my opinion) a more accurate characterization.  
> The SCE proposal penalizes any sender that adopts it (2-fold reduction in throughput with no improvement in latency) in many cases, and gives a benefit that is nearly on par with the L4S benefit (this is still to be shown, but it is theoretically possible) when FQ is used in the bottleneck.  Based on this, why would a sender ever adopt SCE?  Why would the IETF ever want to consider using this last codepoint for that purpose?

	[SM] Because from the IETF's perspective, the important issue should to be how to reliably, robustly and safely enable 1/p congestion control over the wider internet. IMHO that is where tsvw comes in, the claimed (and hyped up*) latency improvements that L4S promises seem more a commercially relevant questions.
	IMHO SCE offers a relative clean, backward-compatible and hence safe way to deploy 1/p-type congestion control that leaves basically all doors open for future improvements, for example in latency-under-load increase. Put differently SCE sets out to tackle one specific important thorny problem and solves it in a clean and minimally invasive way with minimal side-effects, and hence should be considered by the IETF.

*) Hyped-up, because the state of the art today are ~5-10ms latency-under-load increase not 100s of millisecond, sure 1 < 5, but I fail to see any use-case that both will qualitatively suffer significantly by going from 1ms to 5ms additional queueing delay, that is a reasonable to use the wider bet-effort internet as transport medium. THat is not to say that going from 5 to 1 would ne be a good thing, but lest keep benefits and associated costs in a realistic perspective here.

> In comparison, L4S provides a benefit to the adopter (better throughput and lower latency) and no significant penalty to others in the majority of cases (including FQ) and only results in the significant penalty to older systems in some (highly?) unlikely cases if RFC3168 fallback is not implemented.

	[SM] Today, in all realistic current conditions, no ECN-based AQM, both will behave exactly identical, so in other words there is exactly ZERO benefit for the adopter of any of the two ECT(1) definitions. Both proposals, as I was able to get Koen to commit to, aim for per-flow fairness* even though Bob explicitly disagrees**, and both can signal 1/p-type CC response. So far so similar. The biggest difference I can see, is that L4S with its flawed dualQ AQM has a somewhat working implementation of a method how to translate 1/p type responses into lower queueing latency, while SCE currently does not. But dualQ could easily modified to a) use DSCPs for queue separation and b) to use SCE-type signaling for the LL-queue. 
Low-latency queueing and 1/p-type congestion signaling really are two orthogonal issues, that best are tackled independently. L4S demonstrates that coupling them is not the best idea by such questionable engineering like the TCP Pragues hack to work around the dual queue coupled AQM's poor  sharing behaviour at low RTTs. Mind you, that hack is not to account for some undesirable property of code/gear already widely deployed and used in the field, but rather to two components that still have not left really the lab. (Not only that, but the 15ms hack has not landed in the official TCP Prague repository at, and according to Koen is not intended to make it into TCP Prague at least in the current form).

Best Regards

*) Even though it starts to look, that the only robust guarantee that L4S is willing to give is one of "non-starvation" while at the same time aiming to make it appear as if it was delivering equitable sharing between flows of 1/p and 1/sqrt(p). 
	And yes, under sufficiently narrow conditions L4S can deliver roughly equitable sharing, but alas, it fails to do so for the shorter and shorter content-to-end-users paths that get more and more common; the shorter the path the more it gives L4S flows an undeserved and unexpected advantage. 
	This would all be less irritating if equitable sharing between flows would be a pie-in-the-sky objective that nobody ever had achieved. But given the real world existence and deployment of bi-directional FQ-AQMs that pretty much solve the biggest part of the L4S agenda (getting latency under-load-increase down from >= 100ms into the single digit millisecond range) it seems like a waste of engineering resources by the L4S team to having worked hard to re-invent the wheel (pseudo FQ without the guarantees that make FQ a decent "good enough" solution in the first place) instead of adding their good ideas, like getting 1/p congestion control in the field and potentially using paced chirping to help improving the "slow start phase". Sure everybody can decide where to spend her/his time 

**) At the end of Bob wrote
"The main reason the early L4S proponents sunk years into developing the dualQ coupled AQM was to provide a way to do low latency without FQ."

@L4S team, please get your messaging straight, what is it "aiming for equitable sharing between all flows" aka FQ or "low latency without FQ", both seem mutually exclusive.

	By now, I am prone to believe Bob's narrative over Koen's, as it is way more consistent with a number of otherwise hard to explain design decisions that disadvantage non-LL traffic for the benefit of LL-traffic, like the 15ms latency reference target for the non-LL-queue's PIE instance. 

> -Greg