Re: [tsvwg] feedback and thoughts L4S / SCE

Sebastian Moeller <> Sat, 28 November 2020 13:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DDBB13A0D91 for <>; Sat, 28 Nov 2020 05:01:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JJ_NKSlosqxu for <>; Sat, 28 Nov 2020 05:01:05 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B0FD3A0A81 for <>; Sat, 28 Nov 2020 05:01:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1606568460; bh=RilS7EbuNSf70/KILj4zEtOVw+l/eZSOoi1ODpnfNeY=; h=X-UI-Sender-Class:Date:In-Reply-To:References:Subject:To:CC:From; b=Hy4S31asW/baYs+bSmRUGnvwU1fxR65eTylV+Ss94DPyx/PnSOmQgLswbUnzrmYA3 qC08rV5ezT2Ir8FlRx282iLGvZNSEXkd66RGnN165h6ltflXg1iwDPaSmYuQzVnusU ixmYf9+IEzfDBFygn9uGnlkOw2XzOpF8UIOtEALo=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx005 []) with ESMTPSA (Nemesis) id 1N5mGH-1k7R4B1gxH-017E0e; Sat, 28 Nov 2020 14:01:00 +0100
Date: Sat, 28 Nov 2020 14:00:59 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----57Y74JEEQOI36XJRC3N1ENPYGZGVS0"
Content-Transfer-Encoding: 7bit
To: Mikael Abrahamsson <>
From: Sebastian Moeller <>
Message-ID: <>
X-Provags-ID: V03:K1:mnjbWzg58ucMp99WcXeETg+wyxDeLYCpfMleJvsPHWqcsFCZ0YB UjBhvc+UV14GUZ8ZWlHU3J0A1EevSCcCkJ+VEY6xZG80zXqiRTYYwfTcp+WxjE2brVTEFS5 ykOS8n6FOHpetavrHRNjqC0vfy/jVJrgdBADzDE+BAJABEz9u5jz0K/2ScFSZ26ISvWIzzT +WSWP3kDU6uHHaAZANlow==
X-UI-Out-Filterresults: notjunk:1;V03:K0:vXpQ8krpcdQ=:LluhthI7eQp142uvDlgJP5 tT0/Cy1GYKB3u3bFPOL9NjCFxeSOeUSU90BWFFJJHxLRNNrspZ1AQ31NR1TVbcOobbMiXVAMr 8f3CAu2l/7qwu1jn7fG4GOEmCeKcJju+lzpuIS0lv8WE2lP1CydUMgbF/4v4nfkM4ouFlzp/h L3Ey21TkRoU9Ujqgciysa4W1B6g+ePnVrkhkWlVlQvXzbAOX2HV73cHzI54BwsQu43f8fb10Z Bceowafaqq+JMYngo/+NFm5RtQbjuljg/C1xUHSA0Z4x1KzG+cVej8Kb5lcMvf1E8hAyt5G2z 49LR3STHFaqUJLdI8SYVnegybv+s4dmNboIgyWgRl0DHAy/OSqr+b2Zs0xehfj5W2eA3NovGf Ot12Yai73TnpJvP5QB7Bs1rkS5pxxbsh2hLRbjT7+p1wFH/BACZsKScbyTOZ3v+pVigfoTpEb iVu3sBVqzhJKTRpdqvycl52m27EAsW68I5ePaFNXYKvypFbP/GXK1tUBUYn/2MPQCP4S4teAp D4sgEtR1olOlPFt845YAx8TN60v/bfb0ZuiFe/fdlwLhO7iLrDUO77r8O4Lc3yX77HkZuiFTD jWVOsJyb7f53cQ9Q4z7t8Fi4qRoVJ5gwhzLDDKHEW9rZzZ2Wc0wAfArr921ljNQUwb2jFw3DB yhhA7U4s2J1qQyKSQl1oiZ22xnloLlP3+cIzR1PIFFuEkp9MJWHQxLgvRjie749QlPysBnQQM iepcyTNqCEU7EVtAnxUw5OmIdQnBL7NzXGN8vqKDJ3ngKT/9MmjxAna459IGurGX7vYdgpJPH MgV5iq0P3B74gD/s2i+agBNLXJusOdS52ssq4LmH756znKQpdLQBJdV+ZMBrJK2680fsgOlFr 2QJbziSv3jK6mu1nOQjQ==
Archived-At: <>
Subject: Re: [tsvwg] feedback and thoughts L4S / SCE
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 28 Nov 2020 13:01:08 -0000

Hi Mikael,

As it turns out there is a nssfq_codel modul for qualcomm`s nss network acellerator cores:

Is that a sufficient response to put tge hypothesis to rest that acelleration techniques do not offer fq_codel?

Best Regards

On 22 November 2020 15:56:46 CET, Mikael Abrahamsson <> wrote:
>On Sun, 22 Nov 2020, Sebastian Moeller wrote:
>> just as a data point, OpenWrt switched to fq_codel as default qdisc
>on all interfaces some years ago.
>And how often is this fq_codel the slowest link in the chain?
>> I have no numbers how many OpenWrt devices are in the wild, and how
>> commercial home router OSes are based on sufficiently modern OpenWrt,
>> but that is some use. The OpenWrt project also has no official
>Most of the commercial openwrt based devices will not use CPU based 
>forwarding (required to make fq_codel work) but instead has hardware 
>accelerator (which does not do fq_codel).
>> of running instances but for example Qualcomm's QCA Software
>> Kit (QSDK) is based on OpenWrt, so OpenWrt is more pervasive than one
>> would naively assume. That said, the QDSK kernel seems to be quite
>> (at least Kernel major version 2 seems dead now), and I have no
>> which features are back-ported to it.
>If you're using QCA hw-accelerated forwarding then you're not doing 
>> 	[SM] Again a prediction, not a fact, as I said reasonably recent 
>> OpenWrt defaults to fq_codel on all interfaces (that support it) as
>> as on WiFi which with inceasing access rates more and more often
>> the true bottleneck (no numbers, as that is my prediction, based on
>> own experience).
>If you're using HW acceleration, then fq_codel isn't used also on wifi.
>> 	[SM] Given our lack of hard numbers that is telling more about your 
>judgement than about reality.
>Do you have numbers? How many ISP provided routers out there actually
>fq_* ? ISP provided router is the most common in use.
>> 	[SM] And that is pretty harsh. Also unhelpful teminology,
>"irrelevant" I would accept, but invalid is simply the wrong quality to
>argue about.
>> 	[SM] And here we are again at our lack of numbers... As before I
>share your intuition, but it is not a fact.
>> "Fun" fact TCP Prague really is not at all suited to a FIFO world at
>all, as Pete demonstrated.
>Do you have better numbers?
>>> I also doubt we'll see widely deployed FQ going forward because of
>the cost of doing this in hw (and most devices are hw accelerated).
>> 	[SM] An often heard claim that suffers from the fact that that has 
>> simply never been tried at scale, so the cost argument reflects the 
>> status quo not necessarily actual economic "laws", no?
>Do you know of a FQ_* implementation in hardware?
>> 	Also "wide-spread" use is again a claim that should be based on
>numbers (which cuts both ways, so applies to Pete's claim as well).
>Thanks for ack:ing that.
>> QUESTION: Where do you think most choke points live, at the
>> boundary, deeper in the ISP's network, or even at exchange points? My
>> own limited experience points to the ISP-end-user edge, but that is 
>> purely anecdotal.
>The choke point is most often the customer last-mile access line or the
>wifi hop.
>Mikael Abrahamsson    email:

Sent from my Android device with K-9 Mail. Please excuse my brevity.