Re: [tsvwg] ECN as a classifier (was: L4S vs SCE)

Sebastian Moeller <> Wed, 01 January 2020 09:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 95794120099; Wed, 1 Jan 2020 01:07:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Status: No, score=-2.349 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_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ir0GWSWBxn_1; Wed, 1 Jan 2020 01:07:13 -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 9361A120013; Wed, 1 Jan 2020 01:07:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1577869629; bh=5npYIEkSkLJBHVTzIiT7yFKM3A2qpa0ocUTYzST4nx4=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=hRPOXsII21UO++n2Up96NTqmFrQKm5jH2Zwi9Sn5P0jdZBAenqJoXDGGJBH3WwmO1 haDm0XkNgttVQSuTjhkrB4fBllapjxR2dOx6Y/6LPPx8/HYLBRDhr6jJtRvm1E3l8h UR3Q8Kp6dbL81pijFQ3v2p3Jn8AWgWKckdiR9qEg=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([]) by (mrgmx104 []) with ESMTPSA (Nemesis) id 1MLR1f-1j4vff3xlD-00IWOZ; Wed, 01 Jan 2020 10:00:57 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <>
In-Reply-To: <>
Date: Wed, 1 Jan 2020 10:00:54 +0100
Cc: Roland Bless <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Bob Briscoe <>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:YYdNK42oJk4DbRHbYn8BqGF2AAnhcMAY7uxltn12AlaZ8kK53Y/ WYK/yQiNGYx0eY/bmA7wx+5JXWcmic58m3Xv7xdIfO2KeQOnHsrUce5smuWd+h1vK+0JsLq ll+8/E+GCA3xn8H7lnB+43dt6Mnl4hNLFyJYg8rXlp5u+nhaMIZYAIPVd38WKWcAEk/OSRM sZTXAZSJij+5JhpL6G/ag==
X-UI-Out-Filterresults: notjunk:1;V03:K0:KMWkgL4I2v0=:C/w28rs0ygjv6nk26LIGiD eAgiYwPiUMt2+wlI2MJfp58P2DNTInYXWgOzNoObklY9nFcwdV3vAoqJ09skE/uWEEtXppYQs xu66I5nsVlQovWuQkeBI2ywo+dTQ8Kh9WaOgotNjRPC2ZBYttV2cybm8mof7Zb5or06rbdUXG tmwu0bHJQCP2tlHosbx5qd4RymmAov2oYbMMUVou1QZ8LS/qGC7rST+3wVHjt2YB71eKbZ64q vB6V+gDFJWhsTSpZXsliRGTI7xERl62gvL3E/Oc2cwp95cbjelqmM+Wm82TM49DHjQWO7vGBq dHYLivcyeG2rOECQF3T19wbGa5YiQXcqw1bXYa9EfFV3NK7oCNEUwZMj3PrnODpsQy8t3f+g+ WG832Gt5LMAjZ0zZf+QB9t3SuTFv4/C8BX4TBpiGR9SdYYf+2f5mCM5Q24rEUl0KqK61rVptH ia+TI+ZI0dHFXxRpdpa2A0TT0mmSMVhV/oE/z1voSzP2iLZrxt7+8ixzhUXoeE/rYcYV0QzV0 cSXKjVODzY/sqxK6b6uQ/MpX3aEcV9M6oj1DDVfNYMEERUueufft3QtMxOKjxg01Th3rbugYN 7kQjAd3/qzN3bqgSCHhSQnaSW232KQmn0kREAR/XDLxC8aKyiVYeRVi24qfo5tnld7EQleMEe RXFVTyFn+v4q5v20GW9FIxWJpuMqKT8NcNq/kC0oz52qxWbinWgvTcroRTmfOh6U/AA7ay3/L t5kXe0xXr/MjZ29XQ5JCSgGbJGiaGLMwrjJVHE5QJ2/3I5VuCJ9WeTySeTFS6hwleFZydugFk D1q/d+bST/w3FtgtqRPwnEw0iZi5ugSwBqi/Zr52MpX6yTjjbdNzXURW5Cnm8aeBuq339dMsk t/fcD9zkG2XbGEbaGTbt03V/VJCUhKeMh43EPLshRn9mTrczZwemfngmJSAhkWjANuUTJaS2E qN5qaawX68ZZNrvu/yu8qCC7LLDg1CAkqJLWGFRKIULw7c0UF3rfxcGBxaZx5BoPMdK7lLYPT +gWTE5y0rRsWGxk9tjxEsJDBV/7kasSyPC3luIfsWAp50ZXjl7EXhCza+Gf4g09HVQuPt4tny +t+Xma9KV2W321GylvAl/SQOjF9vfzJ4WdQRF8UQKRxnw6q4lcblldVDbzSPVJGo7mJ45MXME FAZf0RQsgce+9Grc+a28Tbh9nOI6/THwdZWZZnbfukCRnN51BwTha3j11EAiALiNH1ewK2kdK u8PrHArFFr4+E7lnkNzIXnj3cWBC7pNmGo4amcrZS68u3m4Hs6FOpp7eNqyQ=
Archived-At: <>
Subject: Re: [tsvwg] ECN as a classifier (was: L4S vs 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: Wed, 01 Jan 2020 09:07:16 -0000

Hi Bob,

more below in-line.

> On Dec 31, 2019, at 17:55, Bob Briscoe <> wrote:
> Roland,
> I just noticed that Koen's response (which I agreed with) snipped some of your responses that I ought to have addressed.
> For this one, I've forked a new thread...
> On 22/11/2019 02:32, Roland Bless wrote:
>> Hi Bob,
>> see inline.
>> On 21.11.19 at 15:44 Bob Briscoe wrote:
>>> On 21/11/2019 09:32, Roland Bless wrote:
>>>> On 21.11.19 at 19:34 Bob Briscoe wrote:
>>>>> On 20/11/2019 21:22, Roland Bless wrote:
>> I find it architecturally cleaner to have an additional ECN codepoint
>> used for indicating "SCE" rather than (ab)using it as classifier for the
>> dualQ AQM.
> The idea that it is abuse to use ECN as a classifier has never been justified, only asserted.

	[SM] Using ECT(1) as a classifier is sub-optimal for a number of reasons, that I will justify here for your entertainment:
1) For classifying between two classes one requires 2 states, or one full bit, ECT(1) however does not meet that criterion, it is a single code-point or colloquially speaking half a bit. Why the theory that ECT(1) can serve as a "classifier" is still maintained in spite of its objective insufficiencies boggles the mind. RFC3168 has an elucidating section giving rationale for the use of two full bits for ECNs two additional states instead of using just a single bit, that shines a pretty good light on this issue and why overloading too much information into a single bit has severe issues.
	Jusy in passing, in L4S classification breaks for packets carrying a CE mark, L4S proposes to carry all of these in the L4S-queue thereby risking increasing packet re-ordering for mis-classified non-L4S flows, fitting well in the L4S approach's tendency to move all the costs of dealing with the "impedance mismatch" between standards-compliant and L4S traffic onto standards-compliant traffic. This btw, is not a slur, this is an objective observation based on the L4S drafts.

2) In essence L4S defines a specific per-hop-behaviour for L4S-marked traffic, and for that purpose there are additional 6 bits reserved in the IPv4 and IPv6 headers, the diffserv bits. Let's have a look at rfc3168 on that topiic:
"One possibility might have been for the data sender to use the fourth
   ECN codepoint to indicate an alternate semantics for ECN.  However,
   this seems to us more appropriate to be signaled using a
   differentiated services codepoint in the DS field."
To which a number of reviewers already concurred.

So I justify the judgment that using ECT(1) as "classifier" is ABUSE, by two lines of argument:
a) does not really work well enough (it fails to act as a classifier under load)
b) it uses an ECN field for a purpose for which dedicated bits are already reserved.

@CHAIRS: For the potential experimental roll-out I propose a requirement/MUST that independent of the ECT(1) code point all L4S-senders also need to set a to-be-defined DSCP, so that the existing filtering and (de-)prioritization infrastructure in the field can be used to implement the desired PHB for L4S traffic.

Best Regards

> The actual position is pretty much the opposite. Below I explain why L4S follows the original way the architecture of the ECN field was defined. Whereas the way SCE uses the ECN field for 2-level marking is counter to the original ECN architecture. 
> The ECN field is unlike any other field in the IP header, because it conveys a value from the sender down the layers to L3 or L2 and it conveys a 'return' value from any node in the network back up the stack to the receiving endpoint.
> Originally, in RFC3168:
> 	• for the sender->network interface, the ECN field was defined as a way for the sender to classify a packet between different code paths in AQM algorithms (drop for 00 vs. marking for the other 3 codepoints). Certainly, it wasn't /envisaged/ that it would be used to classify between different queues. But /architecturally/ there is no difference. 
> 	• for the network->receiver interface, the two semantically identical ECT(X)->CE transitions were defined as the only way for the network to signal congestion.
> The two original standards track RFCs that originally defined ECN tunnelling [RFC3168] & [RFC4301] were both incompatible with 2-level marking like SCE. They required the decapsulation at the end of a tunnel to forward the inner header's ECN field unless the outer was CE. So they would strip any SCE signal applied to the outer header.
> Around 2010, when I was rationalizing these two diverging tunnel definitions into one [RFC6040] (also standards track), I noticed that precluding 2-level marking was unnecessarily restrictive. So we defined the way ECN propagates to the forwarded header from the outer so that future tunnels would support either meaning of ECT(1): either equivalent to ECT(0) or a weaker congestion signal than CE, like SCE. 
> However, the original RFC3168 ECN architecture (that is incompatible with SCE) remains and will remain more widely supported in the Internet, probably for decades. Indeed, even today, the RFCs to make that change to all encapsulations (not just IP-in-IP tunnels) are not past the WG stage yet.
> Tunnels and encapsulations are everywhere. Jonathan M says it doesn't matter if the SCE signal gets black-holed in tunnels and encapsulations. Eventually new ones compatible with the SCE architecture will be deployed everywhere (which will take decades). But it does matter - because SCE wants to claim the last available ECN codepoint, which L4S has already developed to give consistently low latency - within the original ECN architecture. 
> Regards
> Bob
>> Roland
> -- 
> ________________________________________________________________
> Bob Briscoe