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

[Sebastian Moeller <[e-mail]>]

Hi Gory,


> On Mar 22, 2021, at 09:54, Gorry Fairhurst <[e-mail]> wrote:
> 
> 
> Thanks for your thoughts. It's up to TSVWG to work on the specifications, 

	[SM] My initial thought also, but it turned out that the WG left the text and hence L4S' specification effectively to its authors. For example, the idea of putting the L4S experiment behind a mandatory DSCP guard was basically dropped as the authors of the drafts did not want to go there. IMHO that does not look like it is the WG that is in control of the specifications, sorry.


> this isn't about one team versus another.

	[SM] Again I agree that is how it should be, but for example the ECT(1) input or output meeting, was clearly a team sport, where instead of dscussion the relative merits of the two alternative uses of the ECT(1) codepoint, we voted for L4S versus SCE. 


> The "L4S Team" you mention, can develop implementations and encourage their use.

	[SM] Yes, but ATM the only known existing implementation of the specifications FAIL to meet those specifications. It is unclear to day whether that failure is caused by the specifications, the implementation or both. 
	"Ratifying" the specification any time soon, before the source of the failure is at least diagnosed and ideally fixed, seems premature to me. 
And I am puzzled that again we are having a procedural discussion instead of actually addressing the issues in design and/or implementation of the L4S proposals.

Regards
	Sebastian

P.S.: I note that nobody so far addressed the data demonstrating the hard failures of both the DUalQ AQM and TCP Prague, so I guess the good thing is that all of us seem to agree about their existence.


> 
> Gorry
> 
> P.S. I'll send an email on my own thoughts in a short while.
> 
> On 21/03/2021 08:54, Sebastian Moeller wrote:
>> 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 been 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.