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

[Jonathan Morton <[e-mail]>]

> 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