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

["De Schepper, Koen (Nokia - BE/Antwerp)" <[e-mail]>]

I’m open for discussing alternatives, but I think we need first to decide whether using DiffServ is a feature or suicide…

I’m afraid it will be suicide… I don’t think enabling end-to-end DiffServ pass-through is under control of a single party. So at the end L4S will be restricted to single operational domains. Of course allowing L4S without DiffServ won’t stop anyone using DiffServ.

Do people with experience in that field (operators) have a substantiated opinion on this?

Would application providers see using DiffServ as an obstacle?

Koen.

From: Martin Duke <[e-mail]>
Sent: Friday, March 26, 2021 6:15 PM
To: Jonathan Morton <[e-mail]>
Cc: De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]>; Bob Briscoe <[e-mail]>; [e-mail]
Subject: Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)

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]<mailto:[e-mail]>> wrote:
> On 26 Mar, 2021, at 2:30 pm, De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]<mailto:[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