Subject: [tsvwg] L4S status question

From: Sebastian Moeller <[email-masked]>
Date: Thu, 4 Nov 2021 14:45:59 +0100

Dear chairs,

I found the posting cited below on LMKL, and would like to take the opportunity to ask Wes Eddy whether he is willing to give a summary of the current status, please?
I am loath to speculate too far, but Gorry's position might indicate that the LC is considered a done deal.

CITED posting:

From: Gorry Fairhurst <[email-masked]>
To: Jonathan Morton <[email-masked]>
Cc: "Bob Briscoe" <[email-masked]>,
	"Eric Dumazet" <[email-masked]>,
	netdev <[email-masked]>,
	"Toke Høiland-Jørgensen" <[email-masked]>,
	"Ingemar Johansson S" <[email-masked]>,
	"Eric Dumazet" <[email-masked]>,
	"Tom Henderson" <[email-masked]>,
	"Jakub Kicinski" <[email-masked]>,
	"Neal Cardwell" <[email-masked]>,
	"David S . Miller" <[email-masked]>
Subject: 
Re: [PATCH net-next 2/2] fq_codel: implement L4S style ce_threshold_ect1 marking

Date: Mon, 18 Oct 2021 20:43:41 +0100	
[thread overview]

Message-ID: <[email-masked]> (
raw
)
In-Reply-To: <
[email-masked]

Your  summary seems way off the mark to me, and I suggest you ask Wes Eddy for an actual summary of the current status ... 

Gorry

> On 18 Oct 2021, at 16:43, Jonathan Morton <[email-masked]> wrote:
> 
> 
>> 
>>> On 17 Oct, 2021, at 2:22 pm, Bob Briscoe <[email-masked]> wrote:
>>> 
>>> I'll be blunter:
>>> 
>>> In its original (and currently stable) form, fq_codel is RFC-compliant.  It conforms, in particular, to RFC-3168 (ECN).  There's a relatively low threshold for adding RFC-compliant network algorithms to Linux, and it is certainly not required to have a published RFC specifically describing each qdisc's operating principles before it can be upstreamed.  It just so happens that fq_codel (and some other notable algorithms such as CUBIC) proved sufficiently useful in practice to warrant post-hoc documentation in RFC form.
>>> 
>>> However, this patch adds an option which, when enabled, makes fq_codel *non-compliant* with RFC-3168, specifically the requirement to treat ECT(0) and ECT(1) identically, unless conforming to another published RFC which permits different behaviour.
>>> 
>>> There is a path via RFC-8311 to experiment with alternative ECN semantics in this way, but the way ECT(1) is used by L4S is specifically mentioned as requiring a published RFC for public deployments.  The L4S Internet Drafts have *just failed* an IETF WGLC, which means they are *not* advancing to publication as RFCs in their current form.
>> 
>> [BB] Clarification of IETF process: A first Working Group Last Call (WGLC) is nearly always the beginning of the end of the IETF's RFC publication process. Usually the majority of detailed comments arrive during a WGLC. Then the draft has to be fixed, and then it goes either directly through to the next stage (in this case, an IETF-wide last call), or to another WGLC.
> 
> Further clarification: this is already the second WGLC for L4S.  The one two years previously (at Montreal) yielded a number of major technical objections, which remained unresolved as of this latest WGLC.
> 
>>> The primary reason for this failure is L4S' fundamental incompatibility with existing Internet traffic, despite its stated goal of general Internet deployment.
>> 
>> [BB] s/The primary reason /JM's primary objection /
>> There is no ranking of the reasons for more work being needed.  The WG had already developed a way to mitigate this objection. Otherwise, a WGLC would not have been started in the first place. Further work on this issue is now more likely to be wordsmithing.
> 
> Given that the objections cited by the TSVWG Chairs were technical in nature, and related specifically to the incompatibility between L4S and existing conventional traffic, it is clear to me that wordsmithing will *not* be sufficient to render L4S publishable in RFC form, nor deployable at Internet scale.  
> 
> To quote David Black, one of the aforementioned Chairs and also an author of RFC-8311:
> 
>> Two overall conclusions are that a) the WGLC has been productive, and shows significant continuing support for L4S, and b) the L4S drafts should be revised to address the WGLC concerns raised.   The WG chairs strongly suggest that the revisions include limiting the scope and impact of initial L4S experiments on RFC 3168 functionality (both existing usage and potential deployment) to ensure that the L4S experiments are safe to perform on the Internet, paying particular attention to potential impacts on networks and users that are not participating in the L4S experiments.
> 
> It is my recommendation to netdev to stay out of this ongoing mess, by rejecting this patch.
> 
> - Jonathan Morton

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 4 Nov 2021 14:06:03 +0000

> I am loath to speculate too far, but Gorry's position might indicate that the LC is considered a done deal.
Sebastian,

There's still a milestone on the TSVWG charter, and it's not completed 
yet. This is not a "done deal", that's also not how the process works. 
However,  we have gone through the 2nd WGLC process and now have 
collected feedback. We, as Chairs, have noted where new areas of concern 
have been raised - and where we see important new contributions.  We'll 
review the  ID updates that result (the first batch of which were 
recently posted) and we'll make a decision on how to progress things.  
The chairs will finally need to judge and record consensus to publish - 
if there are still people who don't wish to see the document published, 
that consensus will be "rough" (that also will be recorded).

Wes is indeed the Shepherd and I expect he'll be able to best tell the 
plans!

Gorry

---

From: Sebastian Moeller <[email-masked]>
Date: Thu, 4 Nov 2021 16:21:01 +0100

Hi Gorry,

> On Nov 4, 2021, at 15:06, Gorry Fairhurst <[email-masked]> wrote:
> 
> There's still a milestone on the TSVWG charter, and it's not completed yet. This is not a "done deal", that's also not how the process works. However,  we have gone through the 2nd WGLC process and now have collected feedback. We, as Chairs, have noted where new areas of concern have been raised - and where we see important new contributions.  We'll review the  ID updates that result (the first batch of which were recently posted) and we'll make a decision on how to progress things.  The chairs will finally need to judge and record consensus to publish - if there are still people who don't wish to see the document published, that consensus will be "rough" (that also will be recorded).
> 
> Wes is indeed the Shepherd and I expect he'll be able to best tell the plans!
> 
> Gorry
> 

	[SM] thanks for the information, much appreciated. Sorry, that I (misunderstood and) misrepresented your remark over there.

Sebastian

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 4 Nov 2021 11:33:58 -0400

I don't know what you mean by the term "done deal".

In the IETF, Working Group Last Calls ordinarily generate comments that 
require revisions of documents, often non-trivial, before being 
forwarded on to the responsible Area Director.  We are in that state 
with the L4S drafts.

The history described below is wrong in a couple of ways.  At the 
mentioned Montreal meeting, we thought the drafts were nearly *ready* 
for a last call.  We did not have an actual last call then, as new 
people became involved, and raised some concerns that were agreed as 
needing to be worked on in preparation for working group last call.

---

From: Sebastian Moeller <[email-masked]>
Date: Fri, 5 Nov 2021 12:34:50 +0100

Hi Wes,

> On Nov 4, 2021, at 16:33, Wesley Eddy <[email-masked]> wrote:
> 

	[SM] If all changes required are about verbiage and not about "substance", I would say RFC-ification is a "done deal". I might have missed it, but the recent changes to the draft have been more on the verbiage side as I understand. (Yes, I realize an RFC is only words anyway, but I am talking about changes to the design and implementation of the techniques described in an RFC).

> In the IETF, Working Group Last Calls ordinarily generate comments that require revisions of documents, often non-trivial, before being forwarded on to the responsible Area Director.  We are in that state with the L4S drafts.
> 
> The history described below is wrong in a couple of ways.

	[SM] Fair enough. But also not necessarily all that relevant to the LKML discussion, no? (I understand and accept that as chairs Gorry and you have a different perspective on representation of WG discussion/state, but the conclusion "L4S is not yet an RFC" seems not completely off the mark).

>  At the mentioned Montreal meeting, we thought the drafts were nearly *ready* for a last call.  We did not have an actual last call then, as new people became involved, and raised some concerns that were agreed as needing to be worked on in preparation for working group last call.

	[SM] I guess I am puzzled, Jonathan's main point, as I understood it, was L4S is not yet an RFC so there is the chance it never reaches that state) and to some degree controversial, so the Linux kernel might want to hold off on those patches.... I assumed that Gorry was reacting to that point when he said Jonathan's summary being way off the mark...
	As far as i understand the Linux kernel by now has a generalized method to select packets for the ce_threshold treatment, that can be configured to be any bit(pattern) in the TOS byte. Which seems like a decent outcome, given that the ce_threshold feature itself was already implemented, which also is compatible both with L4S reaching RFC status or not. Heck that would even allow to use a different L4S identifier bit leaving both Ect(0) and ECT(1) for rfc3168 use

Sebastian

P.S.: As an aside in the last few years I have seen very litte progress L4S made in addressing its pain-points/failure modes, and yet we are in last call without any real changes to the design and implementation. Even worse, a few of the mitigation techniques, like RTT-debiasing and rfc3168-AQM detection have been tried and essentially abandoned, presumably because they could not be solved robustly and reliably.