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

["C. M. Heard" <[e-mail]>]

On Fri, Mar 26, 2021Sebastian Moeller wrote:

> On Mar 26, 2021, at 18:34, De Schepper, Koen wrote:
> > My first point is that requiring to set a DiffServ codepoint alone would
> already support that.
>
>  [SM] Well, sure, but you came to the ECT(1) decision for a reason (a
> reason I do not agree with, but that is a different topic, I am trying to
> build you a bridge here how to run your experiments without taking the rest
> of the internet down), so I am not going to argue about that. My proposal
> adds an GUARD DSCP for the duration of the EXPERIMENT to allow your
> measurements in live production networks without negative side-effects for
> non-participants. This layer of safety can be removed if the experiment has
> run ist course and measurements in consenting networks has provided data
> that L4S is safe without the DSCP. At which point the DSCP could be
> dropped, try doing that if you only use a DSCP as L4S classifier.


This point sure seems to have been lost in much of the discussion. Note
again: GUARD DSCP for the duration of the EXPERIMENT. NOT DSCP instead of
ECT(1).

I've read several comments objecting that using DSCP to distinguish L4S
traffic is undeployable end-to-end on the general Internet. Well, according
to the intended status of the drafts, L4S is starting life as an
EXPERIMENT, and as such is not expected (or at least should not be
expected) to be deployed on the general Internet. If the WG's desire is to
have L4S deployed on the general Internet as soon as the specs are
approved, then the WG should take Steven Blake's advice and
deprecrate/obsolete RFC 3168 and change the intended status of the drafts,
or else use a mechanism that is backward compatible with RFC 3168, such
Jake Holland's proposal to use ECT(1) -> ECT(0) as the L4S congestion
signal, leaving the semantics of CE unchanged.

Mike Heard