Re: [PATCH net-next 2/2] fq_codel: implement L4S style ce_threshold_ect1 marking

On 16/10/2021 08:39, Jonathan Morton wrote:

quoted

On 15 Oct, 2021, at 2:24 am, Toke Høiland-Jørgensen [off-list ref] wrote:

quoted

quoted

quoted

Add TCA_FQ_CODEL_CE_THRESHOLD_ECT1 boolean option to select Low Latency,
Low Loss, Scalable Throughput (L4S) style marking, along with ce_threshold.

If enabled, only packets with ECT(1) can be transformed to CE
if their sojourn time is above the ce_threshold.

Note that this new option does not change rules for codel law.
In particular, if TCA_FQ_CODEL_ECN is left enabled (this is
the default when fq_codel qdisc is created), ECT(0) packets can
still get CE if codel law (as governed by limit/target) decides so.

The ability to have certain packets receive a shallow marking threshold
and others regular ECN semantics is no doubt useful. However, given that
it is by no means certain how the L4S experiment will pan out (and I for
one remain sceptical that the real-world benefits will turn out to match
the tech demos), I think it's premature to bake the ECT(1) semantics
into UAPI.

Chicken and egg problem.
We had fq_codel in linux kernel years before RFC after all :)

Sure, but fq_codel is a self-contained algorithm, it doesn't add new
meanings to bits of the IP header... :)

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.

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.

I hope this level of brevity was useful for netdev. See tsvwg@ietf.org 
for details.


Bob

It is my considered opinion, indeed, that moving *away* from ECT(1) as the L4S identifier is the best option for improving that compatibility.

I believe there is a much higher threshold required for adding such things to publicly maintained versions of Linux (as opposed to privately maintained experimental versions).

- Jonathan Morton

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/