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

[Bob Briscoe <ietf@bobbriscoe.net>]

On 16/10/2021 08:39, Jonathan Morton wrote:
>> On 15 Oct, 2021, at 2:24 am, Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>
>>>>> 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/