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

Sebastian Moeller <> Sun, 21 March 2021 08:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D2EEA3A199E for <>; Sun, 21 Mar 2021 01:54:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.252
X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v8Aa2WphI6lW for <>; Sun, 21 Mar 2021 01:54:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9211A3A199D for <>; Sun, 21 Mar 2021 01:54:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1616316857; bh=CsPzs7kBVn07PhX6U80AnFXY7Zwqm02n0VkOUbGxeHI=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=fX9ULddQRpOQsn6JOSZTETU3dM/ygD150q4H7Uan7gkmZAbBOUYrUsjMlp/grbkXb 5Y+jqmFZhYboPZGIcy7GBobQKyysvLUmOq0mlAq4dJjgolv6pqxQYrGOWeUCbUQqm7 4P9uKSQjHw1fetCPcxxAyjhxky2vUNHNjCm9DbSU=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx105 []) with ESMTPSA (Nemesis) id 1MQv8x-1l04Gk0Wmt-00O18p; Sun, 21 Mar 2021 09:54:17 +0100
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Sebastian Moeller <>
In-Reply-To: <>
Date: Sun, 21 Mar 2021 09:54:15 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Gorry Fairhurst <>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:KTF8RzPIlRgQH0BQgzPoUpJexxnb51Dz98XXZKYv4f23uEb9/oH U4pQVBo8efmu5mVOd4qsFl5ZGw3byjEWTq0pgnZ5LLjWO1Ht3rpkE2d+HvZ9MMqPu7yQ7WU YMv4y5iFPh7Yy7m6Fktk5P7ffdgTCXurT8gHBDXZOeb2w9uY+8BZREhdiSTQo7jjOqF1jaq vCmj8tDW4G+LS7WCmfM6Q==
X-UI-Out-Filterresults: notjunk:1;V03:K0:qzoHKoCO2AY=:/XWlTe6eZNiLcMrpCEcjXh /kTi23NWY7Ga5w9l4zI8UOI8sQqzWNuRququL4DpNyhL7siyTa1SdY+9Eb9srLWFonhtrYKWw hy1c+bQqSIcDheF+nmpVI5Vr8rLZ4bMaVDMIQS/cvaMqsD0xMQKHLH+FMuDTS+qupCriSdJHi uek48I0ap2YmYgiBz1Pdq7EWW+dvw2xKwZDTKmqz2K7lDXtOvecqFLVaS9A3DrJdHS2Wz0BKF 2v+mHoyDwrxEYXy84zmvheakELTCLlz+pDfBsFZK37uE6grcTF1UFiXq+q50qnCGa0a0cLgTg 5nU0zP+7QrOpKZdjXRHOcGE3BejASrhFX0/bDId22x3DydmMKDnBPJbeWVBvfmVOEtNxgslwa dmQitasivKtOBA3He2JfTX/V17fKn5ty3VyfwE/4HnU+SXUetWyW4WDIWhJJ/8ogbI/XXn2uK lLmiFoCowelGuBqzwgvH+eUuoclvgP7avEzEfPvzk6rJjpdZ+YfUuYD1iDPQwn9dwKHJIMrAi eu9nTNxM2ZiL1syzJG5dQRxQADwuROVE5QDB4yJV/k9C2C91TmBT6umXH/T5UT+2mJsGFVsjL X6azE0PeODcvt9w6iy3cd8jnD8OXPrJ8j63YFjNiPOp6N1hiOvQ6R+LHSrL+PDh512mK6shTf ktvLKDs3Mwzc18xm1tgRnhojAEo0aRTgsYiXDf87bgk33hakxLtU5M3n/3yf413xEIZSHNkJA Gwcdy6Sgf8dSqhRBo8v3G2yJqNpm6u4h/A/PQ+Rx64CaITcjiQiidbwEfVGvd91TFXjMgimGM wH2PXNH0nwgDIkUME5sXWZ5oARwGClL50mCI04ryEnftT6xQHF6QgnjjEe4+aiOKbn23OkMNm eODOwFKnEwA5XbrhNQWg==
Archived-At: <>
Subject: Re: [tsvwg] Adoption call for draft-white-tsvwg-l4sops - to conclude 24th March 2021
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 21 Mar 2021 08:54:26 -0000

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

> On Mar 21, 2021, at 03:55, Gorry Fairhurst <> 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
>> 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 <> 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.