Re: [tsvwg] Follow-up to your DSCP and ECN codepoint comments at tsvwg interim

[Sebastian Moeller <[e-mail]>]

Hi Wes,

Thank you! More below in-line.... 

On March 11, 2020 4:50:01 PM GMT+01:00, Wesley Eddy <[e-mail]> wrote:
> On 3/9/2020 4:10 AM, Sebastian Moeller wrote:
>> QUESTION @Chairs: What are the conditions and aims for the TSVW WG in
> deciding to grant an RFC like L4S experimental status? I would love to
> get a clarification please.
> 
> 
> There are 3 chairs, and I only speak for 1, but the bottom-line is 
> simply "WG rough consensus" (decently described in RFC 7282).

	[SM] Oha, that RFC was in equal parts interesting, enlightening, and unhelpful ;) 

> 
> Beyond that, I don't think we are adding or removing any explicit 
> criteria.  The RFCs on congestion control evaluation cover things that 
> have traditionally been of interest/concern to the community in 
> developing consensus that technologies were safe enough for
> experimental 
> deployment on the Internet.  In the case of the technologies that are 
> proposing to use ECT(1) for experiments today, I don't think this is
> any 
> different.

	[SM] I guess then I want to start a discussion about the starvation issue. RFC2914 about CC principles indicates strongly, that starving-out flows is unacceptable and equitable sharing of bandwidth (modulo some conditions) is desirable. But I will try to start that discussion in a separate thread about whether or not the current L4S implementation and design meets these principles sufficiently.


> 
> As a chair, when sending to the IESG for recommended publication, I
> also 
> want to see that:
> 
> (1) There is wide interest in deploying the technology.
> 
> (2) The concerns with it are understood well enough to be considered by
> 
> people deploying it, and they are aware of what they might want to 
> measure or what means are possible to mitigate problems.

[SM] Quite measured and convincing arguments.


> 
> Sometimes the "experiments" don't clearly succeed (global deployment) 
> nor fail (nil deployment), but wind up very useful in some cases, and 
> not of interest in others.  In the case of ECT(1) (considered by itself
> without any DSCP-scoping), there probably should be some bit of a plan 
> or analysis around what happens if the technology persists in pockets 
> where it's useful, but doesn't have 100% deployment over the Internet. 
> 
> We will need to consider the status of the ECT(1) codepoint, and how it
> can be used in the future whether these experimental specs are 
> successful (widely deployed), partially successful (deployed in 
> pockets), or failed (not deployed, or found defective and eventually 
> un-deployed).

[SM] That seems to acknowledge the fact that even a failed L4S experiment might spoil ECT(1) for a long time. This IMHO is supporting the idea that the experiment should only be started with mechanisms in place that allows a quick abort and recovery of ECT(1) on failure (given that there is an alternative proposal for ECT(1) usage in front of the WG). What are the technical arguments against rolling-out L4S experimentally in a cautious, measured safe and un-do-able way? The biggest arguments I hard so far were convenience (don't want to do more work than necessary) and easy of internet-wide deployment. IMHO the first is understandable but weak, while the second seems rather pre-mature given that L4S experiment and L4S as a a standard can be deployed using quite different methods and restrictions (so experiment under strict control and safety mechanisms and on success deployment under relaxed conditions seems like the obvious strategy).
Especially since the core questions L4S as an experiment is supposed to answer are a) will the positive lab-results also transfer into and materialize in the real-world  internet (functionality) and b) will they do so in a safe and compatible way with the existing internet (safety). 

Best Regards
         Sebastian