Re: [tsvwg] plan for assessing L4S safety [was: plan for L4S issue #29]

[Sebastian Moeller <[e-mail]>]

Hi Wes,

I agree that a topic change was in order. More below in-line.

> On Oct 1, 2020, at 17:33, Wesley Eddy <[e-mail]> wrote:
> 
> I am not sure if your questions are for me or others, but responding to the specific questions:

	[SM] I might not have formulated this clearly enough, the questions are for all, the chairs and interested WG members.

> 
> On 10/1/2020 3:05 AM, Sebastian Moeller wrote:
>> [SM] Before this de-rails any further into abstract concepts, could you please answer a few questions:
>> 
>> 1) Why you consider it essential for these safety tests that the L4S drafts reach RFC status first? Put differently, what unsurmountable obstacles exist today that make it impossible for the required safety tests to be performed right now?
> 
> I haven't heard anyone state this.  Many people have expressed that they are eager for wider experimentation.  I don't know where the word 'required' is coming from in your question, but it sounds like your own requirement rather than something these people agree with.

	[SM] Oh, simply from logic. If the WG makes publication of the L4S dependent on L4S being safe (for the wider internet) as I have taken to understand, the WG needs some criteria to assess safety. And some of these will be hard requirements, "avoid total congestion collapse" comes to mind. I really want to know how the WG is supposed to asses safety, and what criteria the chairs consider. Talking about requiring safety, but not committing to to a definition what is considered safe and what is unsafe can hardly be the WGs final position, so I am clear I am misunderstanding something.


> 
> 
>> 2) And on the topic of failure, will the WG commit to a set of criteria up-front to assess whether a potential L4S experiment succeeded or failed?
> 
> I think the operational document Greg has started editing will be capturing the collected thoughts on what people working with L4S in their networks should be looking for.   But I'm doubtful this is what you're asking for, since you seem to be after more of a global pass/fail flag on all of L4S, if I understand correctly.  I don't recall seeing such in any other Exp. RFC, so it seems unusual to expect.

	[SM] Most experiments reqire the investment of a rare resource like a codepoint in the shared IPv4/6 header either, so maybe a bit more contingency planning might be in order for L4S than for your run of the mill RFCs, no?

> 
> 
>> 3) What to do in the case of failure? Do you consider it out of scope for the WG to require the L4S drafrs ot include explicit section how to un-roll the experiment in case of failure and the expected longer-term side-effects? If no, pleas elaborate why?
> 
> I think this would be good scope for the operational document. There have been some discussions in the working group, and getting the ideas matured and into a draft seems like it would be productive.

	[SM] Great! I might be confused about the hierarchy of RFCs though, I was under the impression that standard > experimental > informational. But if all published ones apply equally, than I do not care too much where the "how to end the experiment" section (for both success and failure) will live. I assume that all the L4S drafts/RFCs will cross-reference each other. ATM, draft-white-tsvwg-l4sops-00 seems to exist completely outside of the other core L4S drafts, but that might change on the next update cycle?


> 
> 
> At higher level, the thread has diverged significantly from issue #29 subject matter and I think lost that focus.

	[SM] Strictly speaking I agree, and changed the topic (not sure whether this will survive due to email headers).

Best Regards
        Sebastian