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

Bob Briscoe <> Thu, 25 March 2021 14:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 94DEF3A233F for <>; Thu, 25 Mar 2021 07:01:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.433
X-Spam-Status: No, score=-1.433 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dB0gxvw0iUIF for <>; Thu, 25 Mar 2021 07:01:02 -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 CB77A3A233D for <>; Thu, 25 Mar 2021 07:01:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; 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=tg78SJdbE4djQFogCcLY8URmp45lFAQkop470EQQp6c=; b=58wHM9Xvf1HnersRkUf3QX2zO rgqFCMzbwuLi74wiIc6WreWln5vVbAm0pTUuEl7rRzyf1PBJwL1rX6A7NX2S/Ek17ewgfa7r1aPjR PbkRw6/xc12jM5xSCcUoJULx/3PCxNhHStTLKdNnjuL/MQ1zKc1EmF5nVbv1wYCYnDhWLF7vUOxrE /QP5V7MxUDt3PpgvzjV4wy11SJDhkziKyYfFFzidEnlpAF3Ex+CA4xg1j1iHBHyLmv6Ki4QTK3Wox LyY0hDSncV7wFRr+L8LEo14se9sDSca3bg9QhipMXN5zCmnwc10WfHAZ52tXg8kH0ujDBTfdfiLPb Y0ZiMmF7A==;
Received: from ([]:60848 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from <>) id 1lPQXj-0003qA-MU; Thu, 25 Mar 2021 14:00:59 +0000
To: Jonathan Morton <>, "Black, David" <>
Cc: "" <>
References: <> <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Thu, 25 Mar 2021 14:00:58 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------95F715536B34D479FE56C680"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
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 14:01:07 -0000

Jonathan, David,

On 24/03/2021 22:23, Jonathan Morton wrote:
>> On 25 Mar, 2021, at 12:10 am, Bob Briscoe <> wrote:
>> 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). 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.

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).

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).

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.

ecn-l4s-id correctly summarizes all the above with the following para:

    Hard to distinguish Classic ECN AQM:  Defining a DSCP to indicate L4S
       is a way to help network nodes identify L4S packets (albeit
       unreliable due to the likelihood of bleaching - see above).
       However, it does not help hosts distinguish between ECN markings
       from L4S and Classic AQMs.  This is because Classic AQMs would
       have been implemented without any logic to recognize an L4S DSCP
       or apply L4S marking behaviour.

More frankly, the amount of time wasted discussing this idea is down to 
an extremely sloppy characterization of the problem in some people's 
minds as something vaguely to do with classifiers. Added to extreme 
vagueness in the distinction between receivers and senders. This is not 
how the IETF should be.

> 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.


>   - Jonathan Morton

Bob Briscoe