Re: [tsvwg] DSCPs and L4S: Label DSCP

[Martin Duke <[e-mail]>]

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 <[e-mail]> wrote:

> On Fri, May 28, 2021 at 3:02 PM Black, David <[e-mail]> 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
>
>>