From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 2AFF83B2A4 for ; Sat, 12 Nov 2022 10:54:17 -0500 (EST) Received: by mail-wm1-x332.google.com with SMTP id h10-20020a1c210a000000b003cfd7f339bdso608427wmh.0 for ; Sat, 12 Nov 2022 07:54:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/SezouCBcjPuYsBktGeGmkWmq+TTDTfZsY6XiPKGE54=; b=frBuMXSq4gH6yR1Rt5H2v2WrjFOK0SV7JdCfqHhA/nhwOQa28CIJ0a9Vw4/AOWE+Zv kJCILHEief3YWRRzvDW9Umxesm+yaVDGKuCsOXTZmlHZ043JCBHdms21/HbaRKsvqbXH yYSTLt3weJ5IINjQif3pna/MnVg5FkeWVw3WoFZARLNMkcogOSpF3ffwj31GypVztMYU HfyEmr1/rIGBSKqrijGU4RadlmV0BDb4VED6v+VBSmBv71KheyJvZI/LIkSi6V+CPR2T GiN79Tti7w2TlgcuenhTFClsc4yt0nm5sSeYkYTmYtHO+6osBB8r+5lzp3ZJSfMwJ9i7 phOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/SezouCBcjPuYsBktGeGmkWmq+TTDTfZsY6XiPKGE54=; b=vtllGeKG9wCqi39fhoehyeyXrLVdQ0T52Oaqt0u+jDNqZX0Rs1tsgDpNvNwE9Gamos qGXhHQmADmAG3YGIlNJWpcvkQ/Byu9HIZyCA6f1WVHrB+HaBnA5055YIr8EvEUZi59+O X5TD7iLjJivpTK4OYIHLtme3sLIWnMtjAgxycFVJKSaAXpxKXtVpfM+phIfaeLHNSPNQ XrWXn8ADAOFlAODN6UWfRj6EN2I1+1tC82VQRgTBMRJ36pvpLWCymfAKwJt3otjTkliL Cujox/uD+rRPgAArJgyjM2vT18WFHoU12G/poBW55bPH80fnTpyPlpsdtZ1mU9OKotmy UTfA== X-Gm-Message-State: ANoB5plAkQf6qH9wUJTLa90dVT+TiXQO7VM3ww1wmNwgDx2BIOpKXhM0 oZZsOTiusfBtbD/F3/EXpJdz9e81yUqaZyNpuY2M9ogN3jQ= X-Google-Smtp-Source: AA0mqf55DqYs2GD8Jvm3mAe8H8tByWozyM7KbyMn2pbqPK9H/FlobE5YmoubKBXAZbbVmX5LSZlTnB4hqE1gQbm+rFc= X-Received: by 2002:a7b:cd82:0:b0:3cf:a6e8:b59b with SMTP id y2-20020a7bcd82000000b003cfa6e8b59bmr4168419wmj.128.1668268454855; Sat, 12 Nov 2022 07:54:14 -0800 (PST) MIME-Version: 1.0 From: Dave Taht Date: Sat, 12 Nov 2022 07:54:02 -0800 Message-ID: To: libreqos Cc: Stephen Hemminger , "aapasqual@gmail.com" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [LibreQoS] libreqos vs a vs paraqum X-BeenThere: libreqos@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Many ISPs need the kinds of quality shaping cake can do List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2022 15:54:17 -0000 Paraqum was kind enough to put up a video of me playing "It GPLs me" in their booth from WISPA, and I had a great talk with the CEO, who I'm cc-ing on this. https://www.linkedin.com/feed/update/urn:li:activity:6994997472536248320/ I was very impressed with their demo. They've already cracked 100Gbit! I looked over their feature set this morning. I (personally) have zero interest in dpdk and vpp. I don't want to give up all the other nifty things a linux box can do by using it, so I followed along on the xdp work - but I concede that these technologies are probably always going to be faster than xdp, and there are a ton of products deployed using it. I'd hoped someone would fund open sourcing a fq_codel or cake implementation for it. (Same goes for freebsd and pfsense which could use a native BQL + fq_codel implementation. The BSD packet buffering scheme is really alien to me). DPDK and vpp were born of the recognition that with conventional processors, the bottleneck is more on the read side than the write side, once you crack 10gbit. I'm also not huge on tcp proxies, in part because they are tricky, and in part because they mask the kinds of performance you actually get out of newer protocols like QUIC. Even ack-suppression I'm of two minds about. Same goes for DPI, in general. But there are obviously folk that dig this kind of feature too. Not presently planning on doing DPI or TCP proxies in libreqos. (we are however looking for suggestions for key features in the v1.4 release cycle: https://github.com/LibreQoE/LibreQoS/discussions/133 # integrations https://github.com/LibreQoE/LibreQoS/discussions/152 # Oses I made a feature request while visiting paraqum. They have a nifty feature of being able to track retransmits (I have no idea how), but they aren't tracking ecn marks, which is a really amazing, latent feature of cake and fq_codel we're seeing more and more of. I really want all cake and fq_codel users to be tracking ecn marks!! And overall, it's a huge market worldwide for various combinations of shaping technologies and I wish them all the best, particularly in APAC (I remember vividly supporting someone using our "arlan wireless howto" in Sri Lanka back in 1999, not that I can remember who it was, and kind of hope we helped spark the internet there, and also my favorite vegetarian restaurant in santa cruz is sri lankan) So in meandering through this pre-coffee email, I really really really want to find ways so we can co-operate on standards like diffserv4, work together with all the makers entering this field to improve transports, ensure independent implementations of cake and fq_codel are correct, improve benchmarking and graphing methods, and view the common enemy, as the packet FIFO, not each other. It's a really huge (set of) markets, and we're all in this bloat together. Preseem, also, is a real pioneer in this market, they also do good research, and if there is some way we can position libreqos, with our "upstream first" philosophy, so that we continue doing good things all across the stack, for everyone - and not go broke - for us to have a natural niche in the evolving and expanding "lower latency internet" ecosystem, I'd be really happy with that, too. I personally want to keep working on making wifi fast, wifi6 and wifi7 need tons of love that cannot be fully handled by a middlebox. I think, but am unsure, Cambium's new QoE product smells like cake also. I haven't had much communications with mikrotik, ever. I think tarana is finally aware they have the bufferbloat problem (in spade= s). ubnt has long had fq_codel in a ton of products (and even backports of cake) but seem asleep at the switch. Some of their products are dpdk (one otherwise excellent 802.11ad product that I know of), others, don't know. --=20 This song goes out to all the folk that thought Stadia would work: https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-69813666656= 07352320-FXtz Dave T=C3=A4ht CEO, TekLibre, LLC