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

[Pete Heist <[e-mail]>]

...

On Fri, 2021-03-26 at 08:54 -0400, Kyle Rose wrote:
> On Fri, Mar 26, 2021, 8:30 AM 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.
> 
> Why wouldn't it be? The point of the proposal AIUI is to require
> networks to take action to explicitly opt-in to this experiment.
> Given the DiffServ bleaching that occurs by default at network
> boundaries, operators that take no action will not find themselves
> ambushed by novel behavior.

I agree- the topic of this thread is the use of a guard DSCP for
experiment. Sorry if I contributed to mixing in other possible uses
early on.

> This approach allows for experimenting with ECT(1) as a classifier in
> a safe (contained, time-limited) way, thus allowing a path toward
> universal deployment (i.e., removing the DSCP guard) if the
> experiment is successful without requiring standardization and
> rollout of end-to-end DiffServ. And it does so (a) without
> permanently burning the ECT(1) code point if the experiment fails,
> and (b) in an opt-in manner that greatly reduces the potential for
> unintended side effects on classic traffic.
> 
> This seems to me like the obvious path toward consensus on an
> experimental deployment aimed at gathering real-world experience
> without first committing to something unproven.

Although an RFC isn't technically required to do this, it should still
serve to codify how DSCP should be used and treated, and also to raise
visibility as a sanctioned IETF experiment. After a successful
experiment at "operator scope" (if that terminology captures it, but
the larger the better), it should be easier to justify and start an
experiment at Internet scope.

I also think that with codepoint space this tight, it's not just about
verifying safety, but also effectiveness. I feel the same way even for
proposals that fall under RFC4774 Option 3 ("Friendly Coexistence with
Competing Traffic").

Pete

> Kyle