netdev - Re: [PATCH net-next 2/2] fq_codel: implement L4S style ce_threshold

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <308C88C6-D465-4D50-8038-416119A3535C@gmail.com>
Date:   Sat, 16 Oct 2021 10:39:19 +0300
From:   Jonathan Morton <chromatix99@...il.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     Eric Dumazet <edumazet@...gle.com>,
        Eric Dumazet <eric.dumazet@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        netdev <netdev@...r.kernel.org>,
        Neal Cardwell <ncardwell@...gle.com>,
        Ingemar Johansson S <ingemar.s.johansson@...csson.com>,
        Tom Henderson <tomh@...h.org>, Bob Briscoe <in@...briscoe.net>
Subject: Re: [PATCH net-next 2/2] fq_codel: implement L4S style
 ce_threshold_ect1 marking

> On 15 Oct, 2021, at 2:24 am, Toke Høiland-Jørgensen <toke@...hat.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.  The primary reason for this failure is L4S' fundamental incompatibility with existing Internet traffic, despite its stated goal of general Internet deployment.  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