Re: [tsvwg] feedback and thoughts L4S / SCE

Sebastian Moeller <moeller0@gmx.de> Sat, 28 November 2020 13:01 UTC

Return-Path: <moeller0@gmx.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDBB13A0D91 for <tsvwg@ietfa.amsl.com>; Sat, 28 Nov 2020 05:01:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJ_NKSlosqxu for <tsvwg@ietfa.amsl.com>; Sat, 28 Nov 2020 05:01:05 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0FD3A0A81 for <tsvwg@ietf.org>; Sat, 28 Nov 2020 05:01:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; 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 [10.27.197.216] ([80.187.108.88]) by mail.gmx.com (mrgmx005 [212.227.17.190]) 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: <alpine.DEB.2.20.2011221548210.26384@uplift.swm.pp.se>
References: <alpine.DEB.2.20.2011201413100.26384@uplift.swm.pp.se> <9B5474B3-4384-4A20-81C3-5251246AA594@gmx.de> <alpine.DEB.2.20.2011221548210.26384@uplift.swm.pp.se>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----57Y74JEEQOI36XJRC3N1ENPYGZGVS0"
Content-Transfer-Encoding: 7bit
To: Mikael Abrahamsson <swmike@swm.pp.se>
CC: tsvwg@ietf.org
From: Sebastian Moeller <moeller0@gmx.de>
Message-ID: <066C60AF-39A3-41EF-B9E9-938AA1A707F5@gmx.de>
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: <https://mailarchive.ietf.org/arch/msg/tsvwg/-0L7cto68Jri-GbWx2gZ5bX6S3s>
Subject: Re: [tsvwg] feedback and thoughts L4S / SCE
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=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:
see https://forum.openwrt.org/t/ipq806x-nss-drivers/12613/2160

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


Best Regards
        Sebastian

On 22 November 2020 15:56:46 CET, Mikael Abrahamsson <swmike@swm.pp.se> 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
>many 
>> commercial home router OSes are based on sufficiently modern OpenWrt,
>
>> but that is some use. The OpenWrt project also has no official
>counter
>
>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
>Development 
>> 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
>old 
>> (at least Kernel major version 2 seems dead now), and I have no
>insight 
>> which features are back-ported to it.
>
>If you're using QCA hw-accelerated forwarding then you're not doing 
>fq_codel.
>
>> 	[SM] Again a prediction, not a fact, as I said reasonably recent 
>> OpenWrt defaults to fq_codel on all interfaces (that support it) as
>well 
>> as on WiFi which with inceasing access rates more and more often
>becomes 
>> the true bottleneck (no numbers, as that is my prediction, based on
>my 
>> 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
>use 
>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.
>
>Fine.
>
>> 	[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
>ISP-end-user 
>> 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: swmike@swm.pp.se

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