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

Jonathan Morton <> Sun, 17 October 2021 12:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5CA963A0D6A for <>; Sun, 17 Oct 2021 05:18:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aoSiezWTqxlQ for <>; Sun, 17 Oct 2021 05:18:35 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 886F63A0D69 for <>; Sun, 17 Oct 2021 05:18:35 -0700 (PDT)
Received: by with SMTP id d13so3438735ljg.0 for <>; Sun, 17 Oct 2021 05:18:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ams7n3RdF+fXSvGvFS6HBjzoePKPkXT/5ewtgnYm2/4=; b=dcHvLZuKFlIjp70b00a0Ctnjao9EvhnRf6FeqkEmTAZtQbiHNXkmmQswhADvOawrhJ b7oMrbrEOGlv10WUVBW55YXfJwX8bpSYWMBXtEB9nCLRixrmkwg8h523fyElkhvD1ULb XewgrxWCQMTiQG20NnMQzArMT8z0HEZA89LWU2nq3l4WLBwmds6YkqJeNjvw8TQUghte 0RjbpLocObwI6MS41Lc8po1asnMQF4sWQcTU8PpGI3QSYWJZdEiMj60RciOy2YDeWoZi 74XqxwLOKdZbbTHNJLSDHu9G3Veunk6KCHqywY7zS/dzeSOPI9s16ZF/4T8gAzJEssgq 2SNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ams7n3RdF+fXSvGvFS6HBjzoePKPkXT/5ewtgnYm2/4=; b=Zjuhq04dfRpF4hMPFfWGDSpcnDksVdDTZk3M3oOoGdshzxkwip5u3VhLfjUAxQmLrd /43R0fFi2kH8/QArzBQoTTwxgHA4MpQ7yljBwUd+0a6A1yHazdYDyP/LvkobJVSZODsq jnBWGQOP8f/binIkig5uLcwlva1KvdgHqJQSWURRscnbN3g/95sBQV3QCKl9HsgfkYkL dmMtXqG/n8dvei6Cr1WbO9mLqWeVmcHMbvkMZIZQIqg+kE+uPuLu5RKez0XVaRNMDWur +nb11NtszWia6Dyp4MejUdzfSO+Qu/unD2xpq3jD8CyX5jPqXrqaMeojcG83QMsVgr3z OZXg==
X-Gm-Message-State: AOAM531Ien8kLGw07sOoWAq83zM8wOZInhUtQlQ6B6DsMiXwjmyX2BgX WSu16T50peA4ZtT3fVEgveXThnPSi9k5tumf
X-Google-Smtp-Source: ABdhPJwsnuuOEJ/BnqWwfYpITkwIdH+9GRI0WwKNk0HHc0Fd7a5QPoWxdwhG4kNjRlkDXztBtVIUKA==
X-Received: by 2002:a05:651c:1504:: with SMTP id e4mr25389127ljf.131.1634473113534; Sun, 17 Oct 2021 05:18:33 -0700 (PDT)
Received: from ( []) by with ESMTPSA id u16sm1226356lfr.260.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Oct 2021 05:18:33 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Subject: Re: [PATCH net-next 2/2] fq_codel: implement L4S style ce_threshold_ect1 marking
From: Jonathan Morton <>
In-Reply-To: <>
Date: Sun, 17 Oct 2021 15:18:30 +0300
Cc: Eric Dumazet <>, Eric Dumazet <>, "David S . Miller" <>, Jakub Kicinski <>, netdev <>, Neal Cardwell <>, Ingemar Johansson S <>, Tom Henderson <>, Toke Høiland-Jørgensen <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Bob Briscoe <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
X-Mailman-Approved-At: Mon, 18 Oct 2021 08:43:21 -0700
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Working Group Chairs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 17 Oct 2021 12:18:41 -0000

> On 17 Oct, 2021, at 2:22 pm, Bob Briscoe <> 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