Subject: Re: [tsvwg] DSCPs and L4S: Label DSCP

From: "C. M. Heard" <[email-masked]>
Date: Tue, 1 Jun 2021 10:35:25 -0700

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

---

From: Jonathan Morton <[email-masked]>
Date: Tue, 1 Jun 2021 21:18:33 +0300

> On 1 Jun, 2021, at 8:35 pm, C. M. Heard <[email-masked]> wrote:
> 
> 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?

My understanding of this is that L4S traffic is not supposed to *exist* outside of the networks participating in the experiment.  The measures to enforce that invariant are:

1: Don't deploy L4S endpoints outside the participating networks.

2: Use existing Diffserv management infrastructure at the participating networks' border to prevent traffic carrying the Label DSCP from crossing the border (or, possibly, to limit their volume to a presumed harmless level).

If I've got that wrong, I expect to hear a correction.

 - Jonathan Morton

---

From: Martin Duke <[email-masked]>
Date: Tue, 1 Jun 2021 13:13:05 -0700

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.

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 5 Jun 2021 15:08:22 -0700

On Tue, Jun 1, 2021 at 11:18 AM Jonathan Morton <[email-masked]>
wrote:

> On Tue, Jun 1, 2021 at 8:35 pm, C. M. Heard <[email-masked]> wrote:
>
>> 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?
>>
>
> My understanding of this is that L4S traffic is not supposed to *exist*
> outside of the networks participating in the experiment.  The measures to
> enforce that invariant are:
>
> 2: Use existing Diffserv management infrastructure at the participating
> networks' border to prevent traffic carrying the Label DSCP from crossing
> the border (or, possibly, to limit their volume to a presumed harmless
> level).
>

I've seen no corrections, and it seems that both Martin and David agree
with this assessment, particularly point #2.  *BUT*:

On Sun, Mar 28, 2021 at 5:35 PM Bob Briscoe <[email-masked]> wrote:

> Many of the arguments for why a DSCP is not useful e2e also apply when it
> is used as a guard DSCP in a single network. For instance, when an IP
> header with a DSCP is tunnelled in pipe mode, it is not propagated to the
> outer. So it won't be visible, won't be bleached, etc.
>

That was in the "L4S DSCP" thread; see
https://mailarchive.ietf.org/arch/msg/tsvwg/A1HQwlbDSEONIEhU9DXOYreG8HA/. As
a reminder, allow me to also remind folks of a message from Olivier Tilmans
with subject "Prevalence of tunnels in mobile networks" at
https://mailarchive.ietf.org/arch/msg/tsvwg/ij5BqzNtMxKV8VbHE8pUevZjx7k/.
The gist was:

3GPP domains are literally a set of tunnels stitching together multiple NFs
> and nodes/equipments.

If the assertions in those messages are substantially correct, there are
good reasons to doubt the efficacy of a Label DSCP even within a
participating L4S domain.

And even if that were not the case, there is the question what would happen
if a Label DSCP did survive, and the traffic so labelled were not filtered
by a participating network at its border. It;s then left to the
non-participating network to do the filtering itself. That is not fair or
reasonable. Participating networks need to protect those who do not choose
to participate.

I think it's clear that what is wanted by the L4S proponents is an
experimental internet-wide deployment, not a set of isolated deployments.
If the WG agrees, it should have the courage of its convictions and declare
that RFC 3168 is obsolete.

No half-measures, please.

Thanks and regards,

Mike Heard

---

From: Jonathan Morton <[email-masked]>
Date: Sun, 6 Jun 2021 06:29:01 +0300

> On 6 Jun, 2021, at 1:08 am, C. M. Heard <[email-masked]> wrote:
> 
> I think it's clear that what is wanted by the L4S proponents is an experimental internet-wide deployment, not a set of isolated deployments. If the WG agrees, it should have the courage of its convictions and declare that RFC 3168 is obsolete.

To quote King Leonidas of Sparta:  "If."

 - Jonathan Morton