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

["[e-mail]" <[e-mail]>]

 Pete, tsvwg,

I can see that the idea of using a guard DSCP is proposed as a pragmatic way to make progress. However, I think an experiment isolated from RFC3168 AQMs by a DSCP would not, of itself, resolve the problem of L4S and RFC3168 AQMs. 

Suppose the L4S folks go away and deploy L4S in such a DSCP-guarded domain. They  make progress on some of the experimental goals listed in draft-ietf-tsvwg-ecn-l4s-id, and come back and say it works really well, and now they want to deploy it on the full internet. At that point, the WG is pretty much in the same position it is now - not knowing how to resolve the RFC3168 issue. Except that the stakes would be even higher, because:

- the L4S folks would have made even more investment in L4S, in a production deployment across multiple companies
- Other folks would potentially have deployed more RFC3168 AQMs
So unfortunately it seems to me that, although it now seems pretty hard for the WG to reach consensus on  how to resolve the RFC3168 issue, waiting for a DSCP-isolated experiment will make this harder, not easier. I think if would be better for the WG to find a path to that resolution sooner rather than later. That's not to say that a DSCP-guarded experiment couldn't contribute to such a resolution, but without some agreement on what the path to a decision looks like, it's not obvious that one is essential.
Alex


    On Saturday, March 27, 2021, 2:20:07 PM GMT, Pete Heist <[e-mail]> wrote:  
 
 ...
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