Re: [tsvwg] feedback and thoughts L4S / SCE

[Sebastian Moeller <[e-mail]>]

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 <[e-mail]> 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: [e-mail]

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