Subject: [tsvwg] Containment (was RE: DSCPs and L4S: Label DSCP)

From: "Black, David" <[email-masked]>
Date: Wed, 2 Jun 2021 02:45:18 +0000

> IIUC this is not intended to be a bulletproof method to avoid RFC 3168 compatibility issues. Rather, it provides a better tool for filtering L4S traffic than "drop ECT(1)", which we definitely want to avoid.

That is a correct understanding, and definitely +1 on "not intended to be a bulletproof method" – as noted in the original Label DSCP email:

A primary purpose of using DSCPs is to enable use of existing Diffserv tools and techniques to better manage L4S traffic

Another view of the Label DSCP motivation is that it improves the ability to use existing tools and techniques to deal with L4S-caused problems if/as they occur, rather than completely preventing problems.

Thanks, --David

From: Martin Duke <[email-masked]>
Sent: Tuesday, June 1, 2021 4:13 PM
To: C. M. Heard
Cc: Black, David; TSVWG
Subject: Re: [tsvwg] DSCPs and L4S: Label DSCP

[EXTERNAL EMAIL]
Mike,

IIUC this is not intended to be a bulletproof method to avoid RFC 3168 compatibility issues. Rather, it provides a better tool for filtering L4S traffic than "drop ECT(1)", which we definitely want to avoid.

On Tue, Jun 1, 2021 at 10:36 AM C. M. Heard <[email-masked]<mailto:[email-masked]>> wrote:
On Fri, May 28, 2021 at 3:02 PM Black, David <[email-masked]<mailto:[email-masked]>> wrote:
This note proposes a simple usage of DSCPs with L4S, hereafter called "Label DSCP". This is a proposal for the WG to consider, adopt, reject, fold, spindle and/or mutilate as the WG sees fit. This note is not direction to the WG from a WG chair.  The Label DSCP proposal is based on Section 3 of RFC 4774, which assumes (but does not require) use of DSCPs to indicate alternate ECN semantics:
[ ... ]
              B. Transport protocols do not react to receipt of specific
                            DSCPs from the network. DSCPs on end systems continue
                            to function as inputs to the network, not as outputs
                            from the network.

What I don't understand is how this proposal prevents an L4S sender from competing unfairly with classic traffic when traversing a non-participating domain.

Doesn't the sender need feedback from the receiver that the label DSCP was received? And the the the receiver is itself capable of providing the type of CE feedback that the L4S send needs?

Sorry if I am being obtuse. It would not be the first time :-(

Mike Heard