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

[Pete Heist <[e-mail]>]

Thanks, draft-briscoe-tsvwg-l4s-diffserv is one that I hadn't seen
before. It seems to discuss more the general implications of using DSCP
in combination with the proposed ECT(1) as L4S-ID classifier, rather
than using DSCP as a way to address the safety concerns that result
from the ambiguous definition of CE that ECT(1) as L4S-ID introduces.

I did notice that section 7.2 of this draft might become less
complicated if the L4S-ID were a DSCP, but that's an aside really.

Pete

On Wed, 2021-03-24 at 12:46 +0000, Gorry Fairhurst wrote:
> So injecting a little more history here.
> 
> Some previous discussions are:
> 
> When discussing, it was known that RFC4774 would allow
> experimentation 
> with a diffserv domain (e.g., as in RFC 6660), but the practicalities
> of 
> deploying an end-to-end Internet transport required an RFC to use a 
> method that was not protected by a DSCP. The discussion on whether
> the 
> ECN Plus a Diffserv Codepoint (DSCP) was also noted in the appendix
> of 
> draft-briscoe-tsvwg-ecn-l4s-id-00 in 2015.  R
> 
> the AQM working group in draft-briscoe-aqm-dualq-coupled-00 in 2015.
> 
> The interaction with DSCPs was revisited in 2018 
> (draft-briscoe-tsvwg-l4s-diffserv-00), after RFC8311 enabled such a 
> deployment experiment using ECT(1).  That which explains how the two 
> approaches interact, how they can be arranged to complement each
> other 
> and in which cases one can stand alone without needing the other.
> 
> Gorry
> 
> On 24/03/2021 11:01, Pete Heist wrote:
> > I'll just add to the sentiment that I think the use of DSCP is
> > still
> > worthy of consideration. Beyond the use of a single DSCP on all
> > traffic, there may be other alternatives that address at least some
> > of
> > the concerns in B.4.
> > 
> > Pete
>