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

Bob Briscoe <ietf@bobbriscoe.net> Tue, 31 December 2019 16:55 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A465212088B; Tue, 31 Dec 2019 08:55:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id KbksLXq7jNHH; Tue, 31 Dec 2019 08:55:27 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com []) (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 02C4D120888; Tue, 31 Dec 2019 08:55:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rud0irxzTfGTSCuB7t78iiCzWlnSscs6jin0y5HksZ0=; b=nOQ5uE4Ew/S/NOY0SMy/8DQbh g802NTINx98bPZ3MbGPLousk771yY5+HZtUYsy0TdoMRpJv4COTroT5V0Zxnvict/X1nG6OrfmlIN TZa7462/AnWMn9cKfImYDzsxstM/nEm0E0JJan/zSA4pagrqtSSpgLRYZeexrKXDJV849p9Kh05fD gGE3kJ+RmaXd2SdnQQcDp8Kh1xoEofVOb8oDsiGANmBVyBI4HdzGbVvhvbR6LHWAiT09I3lw5rH0m f9m2bPkjLWVB0dUorpguL7WUjXB5PsH6l2K3I2LkrL1Lw/h6wqAX7RQVrKkLrycQ5hVPkNpc+vsEt RFvDjJYBg==;
Received: from [] (port=49972 helo=[]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <ietf@bobbriscoe.net>) id 1imKnk-0002Tu-UG; Tue, 31 Dec 2019 16:55:25 +0000
To: Roland Bless <roland.bless@kit.edu>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>
References: <HE1PR07MB44250F3C4E6A744DDCC3DAFCC24C0@HE1PR07MB4425.eurprd07.prod.outlook.com> <ad7b763e-b3dd-36cf-a9c5-7de99476babb@mti-systems.com> <12ED7632-5E3E-4EB9-B65E-8A8324067C9A@akamai.com> <5DD4BB25.3060700@erg.abdn.ac.uk> <5658232C-07D5-4C89-B16A-58A928332FC6@gmx.de> <HE1PR07MB4425D989D4A266C73331FFA5C24F0@HE1PR07MB4425.eurprd07.prod.outlook.com> <CAJU8_nUK5cZLFE-0UBzf0a7T0hC7C+CpCsUy_+ZU_p4oxW9BmQ@mail.gmail.com> <HE1PR07MB442560D0715BC921AB9B7FE3C24F0@HE1PR07MB4425.eurprd07.prod.outlook.com> <AM4PR07MB345968E8C665304DFBD5B11FB94F0@AM4PR07MB3459.eurprd07.prod.outlook.com> <228d061d-f25e-b350-4a6e-2aea827a590c@kit.edu> <e5a7ed0e-90cb-10a9-c55f-0ba8d2144ecd@bobbriscoe.net> <1ed5e25f-d105-8866-99fb-5fce181bbbbe@kit.edu> <5d36ceb0-d03f-6fee-c7ea-e803fbfa606f@bobbriscoe.net> <151fd71f-bdc5-a140-104f-e924a2b7dc16@kit.edu>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <7fff2c49-8519-2a40-8e6c-67a9de9b722c@bobbriscoe.net>
Date: Tue, 31 Dec 2019 16:55:23 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <151fd71f-bdc5-a140-104f-e924a2b7dc16@kit.edu>
Content-Type: multipart/alternative; boundary="------------509890FFACE2946D47FF3A27"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/uc_tY0PoRkCLxuJp99ajBtQAf5s>
Subject: [tsvwg] ECN as a classifier (was: L4S vs SCE)
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: Tue, 31 Dec 2019 16:55:30 -0000


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.

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.



> Roland

Bob Briscoe                               http://bobbriscoe.net/