Re: [tsvwg] Adoption call for draft-white-tsvwg-l4sops - to conclude 24th March 2021

[Sebastian Moeller <[e-mail]>]

Hi Gory,

I just hoist your response to the top to make things easier to read:

"I think people are well aware of your own thoughts. This email is part of a thread on the planned working group adoption of draft-white-tsvwg-l4sops."

Which puzzles me for two reasons:

a) The current state of L4S design and implementation: data I cited shows catastrophic failures of L4S's two core components under realistic conditions. Why this is not considered a show-stopper and/or all-hand-on-deck situation for the WG and team L4S, is hard to understand. 
	Also, why people in this WG are willing to just ignore that fact instead of engaging in a discussion of how to meaningfully remedy that (so changing the actual L4S core technologies and not just watering down the drafts text, to "legally" permit tose failure modes). So what is the hurry of adding yet another L4S draft, which in an ideal world would probably need major changes once the other L4S drafts are actually fixed?
	I understand that everybody is entitled to their own opinion and also to ignore other's opinions, but we all have to operate on the same set of data, and it is not my subjective judgement (which would be L4S: " too little, too late") but hard cold data that shows L4S failing. Ignoring that now, will not reflect well on the IETF and this WG once L4S hits the internet and starts to disintegrate, sorry. I have heard excuses that this is part of the IETF process, but I do not see chapter and verse in the RFCs that a WG needs to entertain incomplete glacially advancing internet drafts for all eternity, sending team L4S away with the home work to fix their stuff seems well in the purview of this WG. Heck the WG could even increase the motivation for team L4S to act fast for a change, by ending the ban on oher proposals for using ECT(1) (under the rationale that the current state of L4S demonstrates that ECT(1) as network input simply does not work, at which point the WG decision to use ECT(1) as input becomes moot)).

b) The ops draft itself is also not ready. I gave detailed feed-back (at multiple stages in its development and ) and have (unfortunately) have read it multiple times. How about we first let this last feed-back round play out before making adoption calls?




	All that said, my prediction is that we as a WG are going to accept the L4S drafts in autumn as is as experimental RFCs (as far as this WG can, I understand that we  will not have the last word, but I expect no headwind in the later process either, as detailed evaluation and judgement seems the prerogative of the WGs, so higher ups will assume due diligence from the lower stages by default). With the fig leaf that the 4S-ops draft would fix up the safety story for the L4S design and implementation. And that is something I do not think to be a correct (and ops draft can not retroactively defang dualQ's mis-design (unless the recommendation were :never use dialQ")).
	The sad part is, all of this is not rocket science. For example requiring a guarding DSCP for the duration of the experiment to ascertain that only knowing and willing parties participate in the experiment would have beed relative easy to specify and would have been something where an OPs draft could shine, by giving the right points how to implement passing of said DSCP from participating to domain (e.g. SLAs, TCAs, ...) Alas, the draft did not, it did add however a few gratuitous paragraphs of what I call L4S-fan-fiction. I guess a possibility squandered.


Best Regards
	Sebastian



> On Mar 21, 2021, at 03:55, Gorry Fairhurst <[e-mail]> wrote:
> 
> On 20/03/2021 23:54, Sebastian Moeller wrote:
>> Hi Gorry,
>> 
>> I am puzzled, what has changed in regards to the documented short comings of L4S core technologies the dual queue coupled AQM and TCP Prague in respect to what is claimed in the internet drafts that would justify for the drafts to proceed in the process to gain experimental RFC status?
>> 
>> A quick look at https://camo.githubusercontent.com/0ca81a2fabe48e8fce0f98f8b8347c79d27340684fe0791a3ee6685cf4cdb02e/687474703a2f2f7363652e646e736d67722e6e65742f726573756c74732f6c34732d323032302d31312d3131543132303030302d66696e616c2f73312d6368617274732f727474666169725f63635f71646973635f31306d735f3136306d732e737667
>> should help refresh the memory how dualQ and TCP Prague fare in comparison with the status quo in the internet, a dumb FIFO in regards to equitable sharing*.
>> Giving dualQ's main reason to exist is to equitably share between the new L4S LL-queue and what is called the classic-queue, this failure alone should IMHO disqualify L4S from any further discussion/progress in the WG to give team L4S the time and incentive to fix this. But alas, not my call to make so all I can do is remind everybody that these short-coming/failures are no secret and nobody should be surprised if L4S in the real internet under-deliver in its (over-)promises. 	Unless somebody can explain why this failure easily testable in the lab will not materialize in the real internet?
>> 
>> 
>> Best Regards
>> 	Sebastian
> Sebastian,
> 
> I think people are well aware of your own thoughts. This email is part of a thread on the planned working group adoption of draft-white-tsvwg-l4sops.
> 
> Gorry
>>> On Mar 20, 2021, at 09:13, Gorry Fairhurst <[e-mail]> wrote:
>>> 
>>> On 19/03/2021 14:39, Dave Taht wrote:
>>>> I think this working group has far too much on its plate, and too many
>>>> unresolved issues elsewhere to adopt further work on this subject.
>>>> 
>>> <snip>
>>> 
>>> If people on the list plan to read and review draft-white-tsvwg-l4sops, they should say so on this list before the end of the adoption call period.
>>> 
>>> Completing the adoption call is considered by the Chairs as an important step towards completing the following work items:
>>> 
>>>     Oct 2021     Submit "Identifying Modified Explicit Congestion Notification (ECN)
>>> 
>>>     Semantics for Ultra-Low Queuing Delay" as an Experimental RFC
>>> 
>>>     draft-ietf-tsvwg-ecn-l4s-id
>>> 
>>>     Oct 2021     Submit "DualQ Coupled AQM for Low Latency, Low Loss and
>>> 
>>>     Scalable Throughput" as an Experimental RFC
>>> 
>>>     draft-ietf-tsvwg-aqm-dualq-coupled
>>> 
>>>     Oct 2021     Submit "Low Latency, Low Loss, Scalable Throughput (L4S)
>>> 
>>>     Internet Service: Architecture" as an Informational RFC
>>> 
>>>     draft-ietf-tsvwg-l4s-arch
>>> 
>>> Please respond by 24th March 2021,
>>> 
>>> Best wishes,
>>> 
>>> Gorry, David and Wes
>>> 
>>> tsvwg co-chairs.