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

[Pete Heist <[e-mail]>]

Alex,

I agree with this point overall. Although, a well conducted experiment
in congestion control has a funny way of yielding new information that
may be more consequential than what you were trying to look at in the
first place.

It becomes important what is tested, by whom, and what the criteria for
success are. And among other questions- if nobody in the test group
reports anticipated problems, but they still exist, what then? I think
this is also in line with what you're suggesting.

It seems to me that, short of (and in addition to) a guard DSCP for
experiment, the fundamental issue of semantic compatibility with
RFC3168 will need to be addressed head on, somehow.

Pete

On Mon, 2021-03-29 at 13:23 +0000, [e-mail] wrote:
> 
> 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
> 
>