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

[Martin Duke <[e-mail]>]

Speaking as an individual,

Bob has identified all of the problems with using DSCP for L4S. Among them
is running L4S through a tunnel.

Another axis of discussion was changing the L4S signal to be ECT(1)->ECT(0)
and preserving the CE signal (thread: [1]), which comprehensively solves
the coexistence issues. But this fell down, partially because of the
(needless) RFC6040 tunnel decap behavior, which will revert any
outer-header changes. There are some other problems, of course, they don't
affect bystanders and I don't see them as likely to be fatal.

Honestly, if we're going to break L4S in tunnels anyway, I would just as
soon break it with the semantic change and not take all the other DSCP
baggage that Bob describes. We could even bis the mistake in 6040 so that
"eventually" the needless behavior goes away.

This is not a statement in favor of 1->0 marking. It is a statement that if
the WG is going to insist on a DSCP to ship this design, I would prefer
1->0 over that.

Sorry to complicate the discussion.

Martin

[1] https://mailarchive.ietf.org/arch/msg/tsvwg/TDMKRyH9E6zho6VkiXDYes7FZK0/

On Fri, Mar 26, 2021 at 7:00 AM Jonathan Morton <[e-mail]>
wrote:

> > On 26 Mar, 2021, at 2:30 pm, De Schepper, Koen (Nokia - BE/Antwerp) <
> [e-mail]> wrote:
> >
> > I understood the goal of your proposal. But before diving into the
> details of a DiffServ-based proposals, I'm taking a step back asking: Is
> using DiffServ an option at all. I don't believe so (see other reply to
> Steve's mail related to the reason for deployment).
> >
> > As a second step after this, "IF" using DiffServ is an option, then L4S
> and SCE can get married and we can benefit from both.
>
> In recent days I have put forward two distinct ways to use Diffserv in
> this context, both of which I believe are workable.  The one I prefer is of
> course the one involving SCE-type signalling rather than L4S-type
> signalling; it consumes fewer DSCPs and has fewer failure modes.
>
> In the SCE context, Diffserv is useful for three things:
>
> 1: Protection of early experimental deployments.  This is temporary.
>
> 2: Enabling dual-queue AQMs to perform SCE classification and signalling.
>
> 3: Allowing SCE AQMs to distinguish SCE and non-SCE traffic embedded in
> the same tunnel.
>
> SCE itself is compatible with existing dumb FIFOs, policers, dropping
> AQMs, and RFC-3168 AQMs both single and multi-queued, without the
> assistance or need for any Diffserv mechanism.  Most SCE AQMs will probably
> have AF or FQ functionality to ensure good compatibility with conventional
> traffic.
>
> Diffserv is strictly an enhancement to SCE, which can be deployed in those
> contexts which benefit from it.  The CDN -> ISP -> subscriber path is an
> ideal context for deploying a coherent Diffserv system.  I think that
> dovetails very nicely with the technical needs of DOCSIS Low Latency.
>
>  - Jonathan Morton
>