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

[Ingemar Johansson S <[e-mail]>]

Hi Pete, Kyle, Charles, Sebastian, Jonathan

CC others

 

I have followed this discussion for a while now. 

It is possible in a 5G system to set up traffic filters that include 5-tuples and DSCP + more, so what you propose is possible. 

But with that said, I don’t at all see that this needs standardization and why this would be needed as part of the L4S work. In addition, your  intended purpose with such an guard DSCP is quite likely to be met with confusion among 3GPP operators as there is no evidence of RFC3168 AQM in 5G systems. 

 

I only see that this discussion goes at length to protect classic ECN enabled traffic in the possible cases where network nodes implement RFC3168 AQMs (or FQ-CoDel) and omits the fact that these are eventually either upgraded or replaced over time. 

IANA already lists ECT(1) as intended for experimental purposes only so I would say that it is a bad idea long term to continue to claim ECT(1) for RFC3168 AQMs. 

 

/I

 

From: tsvwg <[e-mail]> On Behalf Of Pete Heist
Sent: den 27 mars 2021 14:33
To: tsvwg IETF list <[e-mail]>
Subject: Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)

 

...

 

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] <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. 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