Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)

Jonathan Morton <> Thu, 25 March 2021 16:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F0C93A2792 for <>; Thu, 25 Mar 2021 09:58:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ieBZnMrSDZQL for <>; Thu, 25 Mar 2021 09:58:18 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB5B83A278F for <>; Thu, 25 Mar 2021 09:58:17 -0700 (PDT)
Received: by with SMTP id b4so3546393lfi.6 for <>; Thu, 25 Mar 2021 09:58:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=v59iWtaVcn9pcwYC3Z+2gGy2SH3hy2zwfeWMAN1uNzY=; b=Mly9YEEENriUv7Io2L2e2CM0/UB2Mpzv64bErOtvmr7QdaQcrzm7v+/qYNgqC89Uqb lZPO6375t3rHIbZFSNckdXXqs3bK/T5tu4KpopJpIKH49XdlyBMe+IsF6uPCgApHi1q8 OAm55BmDYbpYmO10hGox9htsLZuOO2OgBCGAWpfKDzfiSmqO4vYt5F/kIVnBB6+dh0ed EIOvL9XubbBQ7CkwY7CbRhejnI3U0iakqxDL31rseV719DEDzw2mOS/27MH6gSUCnopx Jyb02equYjd+NPtDc21pigZhpn8kQVEZ72AdtK6d3oA/edz8GgSZaUyTQq4HDEnNFBhS 8f1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=v59iWtaVcn9pcwYC3Z+2gGy2SH3hy2zwfeWMAN1uNzY=; b=uWChvLtNm1osA0lYM32zKBuBvxIWAFSWZPDNLwronkHEO+djzwt418BAplwImfNTki P1iW76sxd8w3GQF6Ex6M37mgRmKEyI6DkdKf0Ucq7lyjWeWjxt78DFd3bVit/a1Wzvwu hIMXeQdIhqarKQPBcycqHlfvS2ukOLQXaRKW2W/iNezwCNyqaQ/V/YitH8LfKC8OFWwN uo4byuyTFwCpKPfaoCFUcQVXX4pm0CktrSURJwYq30YTNcd8CvzZ0U0ExmYS72bH++5T iaIbvYyYEUcdMKWjaT5sPGoP8j4R2nQU32BLGeD8pWJLsWHcWur0Ril/TbnDj4msjO1s oqNw==
X-Gm-Message-State: AOAM530CTF7fgRgNHnGc4N95BY22dZUFb6YuaR3y5miImtf7z1pGp6EF E2aWqd71nhC3ycdCxCMt9Rg=
X-Google-Smtp-Source: ABdhPJy6d9zwBwCqdhRcSJFK5EP8t029lZpeSVKpFNEl3myYg+fc9IvGOrEPFIMTi3wbCRtJnyqjpg==
X-Received: by 2002:ac2:5dcf:: with SMTP id x15mr5414337lfq.176.1616691494387; Thu, 25 Mar 2021 09:58:14 -0700 (PDT)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id u9sm817802ljd.130.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Mar 2021 09:58:13 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Thu, 25 Mar 2021 18:58:12 +0200
Cc: "Black, David" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Bob Briscoe <>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <>
Subject: Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)
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: Thu, 25 Mar 2021 16:58:24 -0000

>>> Can someone explain for the record how using a DSCP as an L4S identifier would solve the CE ambiguity problem?
>> It doesn't.  It only allows containing the resulting harm to participating networks, thereby protecting (most) innocent bystanders.  It's enough, I think, to conduct a field experiment to discover just how bad the problem really is in practice.
>> This is predicated on the notion that the L4S-ID DSCP(s) are bleached or dropped at the participating networks' border, and in the case of border bleaching, that L4S endpoints interpret CE marks *not* carrying the L4S-ID DSCP as per RFC-3168 or RFC-8511.
> [BB] "Predicated on the notion" is posh for "it depends on a string of leaps of faith" (LoFs).

I really don't like your tone with this phrasing.  But let's put that aside.

> Specifically:
> LoF (1) The receiver somehow feeds back the arriving DSCP to the sender, which would require new IETF work in QUIC, TCPM, RTCP, etc. The only use-case to justify DSCP feedback would be to make this L4S-ID DSCP idea work. And this work hasn't started anywhere yet. That's not just a leap of faith. It's a leap into the abyss.

Are you arguing here that the current L4S design is so thoroughly baked into existing standardisation work and/or implementations that not even minor changes can be made?  It sounds very much like it to me, and that is very troubling for the prospect of making L4S safe to deploy beyond an Option 1 (completely isolated) context.

In any case, I have already shown you a way to feed back the presence or absence of a particular DSCP.  Simply refrain from emitting the special DSCP, except on the initial SYN, unless you received the appropriate special DSCP on all valid packets received on the connection.  That gives you a very easy way to switch the connection into "Classic mode" if it strays outside the approved path.

> LoF (2) There are no FIFO RFC3168 AQMs a) upstream of the participating network, b) downstream of it, or c) within it (see details below).

Incorrect.  Remember that when using a DSCP as a containment mechanism, it is assumed (as I spelled out previously) that the borders of the network at least bleach that DSCP, and may even block traffic carrying it.  That's how containment works.  So if the L4S traffic crosses a border of the participating network, it automatically switches to Classic mode and there is no more problem with RFC-3168 AQMs on any part of the path.

Which leaves open two scenarios where an RFC-3168 could be encountered without crossing a border:

1: Within the participating network.  But all RFC-3168 AQMs are supposed to have been removed from such a network before L4S was deployed on it.  So either the onus is on the network operator (who is at least an "interested observer") to deal with the problem, *or* the RFC-3168 AQM is present specifically for the purpose of experimentation, eg. to find out how the combination with L4S traffic really works in the real world.

2: The path runs entirely outside the participating network.  This implies that two communicating L4S endpoints were deployed outside the experimental network, which would violate the spirit of the experimental deployment and should not be allowed.  The two-DSCP scheme I outlined in my other post specifically attempts to detect and protect against this eventuality.

> LoF (3) That's before we get to all the other reasons for why using two fields (ECN and Diffserv) as a classifier would rarely work for those who /do/ want to use L4S (in Appx B.4 of ecn-l4s-id already pointed to on this thread).

I do not accept Appendix B.4 to be a valid set of arguments against using DSCP for this purpose.  If nothing else, it does not appear to consider any form of the two-DSCP scheme I recently described.  I would encourage you to give it a serious, principled consideration.

> Now let's see how realistic LoF (2) is by putting this DSCP idea to the test - by hiding these needles in each type of haystack:
> a). Upstream:
> Imagine a FIFO RFC3168 AQM in the queue of a home router in the upstream direction. An L4S client sends L4S packets through this AQM, which marks some as CE. Then the network participating in the L4S experiment delivers them, with the L4S-ID DSCP intact, to an on-net server. But the CE markings were RFC3168 not L4S. 
> b) Downstream: 
> Consider an RFC3168 AQM in the network of a corporate site or campus network receiving traffic from a connected L4S-participating network. Or perhaps on the access into a data centre connected to the participating L4S network. Same problem; the DSCP says its L4S, but the CE was RFC3168. 
> c) Within: 
> Consider an RFC3168 AQM within the network participating in the L4S experiment. Same problem. The participating network delivers the packet with the L4S-ID DSCP intact, but the CE marking is RFC3168, not L4S. 
> In this last case, the L4S-paticipating network has to use techniques like those in l4sops to make sure any FIFO RFC3168 AQMs don't mark ECT(1). That's no different to if ECT(1) alone was the identifier.

Thank you for confirming that you understand that using ECT(1) alone as the identifier suffers from all of these problems.  That was a big sticking point over the past two years, and I'm glad we can now get past that.

>> I refer you also to my recent post titled "L4S, DSCP, and RFC-4774 Option 2" in which I give a more detailed explanation of a two-DSCP proposal.  The short version is that a version of L4S using that scheme would have *some* positive confidence whether or not they were receiving L4S or conventional marking, without the need for heuristic probing or monitoring.
> This requires the same 3 leaps of faith as above. 

No, it does not.  I encourage you to re-read that and carefully absorb my explanation of how it works.  I think you will find the exercise very enlightening.

 - Jonathan Morton