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

[Gorry Fairhurst <[e-mail]>]

On 26/03/2021 12:54, Kyle Rose wrote:
> On Fri, Mar 26, 2021, 8:30 AM 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.
>
>
> 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.
And endpoints and a new way of using DSCPs with transports.
> Given the DiffServ bleaching that occurs by default at network 
> boundaries, operators that take no action will not find themselves 
> ambushed by novel behavior.
>
Does it?
> 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.
That didn't and doesn't require an RFC.
> 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.
>
Actually I agree, and avoids potentially obsoleting ECT(0)? - which is 
another possible way out if we have a problem, as discussed earlier this 
week.
> 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.
>
> Kyle

I'm getting frustrated by that inference that the WG has somejow failed 
to deliver something. What is unproven? - Is it that the advocates who 
wanted a backwards-compatibility mode have failed to produce a method? 
data on ECT(0) marking? - or where you refering to something else? 
Please be specific.

Gorry