From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass smtp.mailfrom=; dkim=pass header.d=gmx.de header.i=moeller0@gmx.de; arc=none (Message is not ARC signed); dmarc=pass (Used From Domain Record) header.from=gmx.de policy.dmarc=quarantine Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by mail.toke.dk (Postfix) with ESMTPS id 408E911D00BE; Sun, 07 Jun 2026 11:03:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1780823028; x=1781427828; i=moeller0@gmx.de; bh=GZxtDzBz/oWmsXsgkWbQa5aqmmiDXTVQGFspSX5xW8A=; h=X-UI-Sender-Class:Content-Type:Mime-Version:Subject:From: In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id: References:To:cc:content-transfer-encoding:content-type:date:from: message-id:mime-version:reply-to:subject:to; b=fcnoKaWKo2jR4ItwmFgfu7j8bMBASFkkKA/omYeKn79IJerDhbowzx8qeoqCZym7 xk2jmMWhxSSm2dwwoLgYhJi8/6YTgn4hCCQIjZ2lcZYWokSi2wGMeMcE3gl4gYUhw mF8c1dyzvQnrQlg2K2yJfNGDKp4jLWV4IEjd1LJzdIrdKEsPK9JES1eg7R87M4r7R UZuC3L/TGMx7ADTexhDs9zdfco8j+fcV2lgi1JgoQ5R2zTdQFgwcMmhJzSTOMVP4r SR420qoqVdZNcCzJgDXNT2ah9hRSiks+mO6okzKmiGkQS3JN8Wq6eh1WNBQmbNTdS wfl12MtDkHM+swFPMg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from client.hidden.invalid by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MkYXs-1wyJQY1VPi-00mXRy; Sun, 07 Jun 2026 11:03:48 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\)) From: Sebastian Moeller In-Reply-To: Date: Sun, 7 Jun 2026 11:03:37 +0200 Cc: codel@lists.bufferbloat.net, bob.mcmahon@umbernetworks.com, dan , Cake List , Make-Wifi-fast , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <52CE3DA7-EC5A-4FF8-A88E-26A7A6661983@gmx.de> References: <0oq1n88q-36qn-p6s7-699s-p4nr0440p950@ynat.uz> <8e14c6935753c6263351ad00ec59b9cb@umbernetworks.com> <055e42685cddfa4c1a4ff4da089996eb@umbernetworks.com> <7455E3B4-7FB4-4D40-A900-B31151D12F6F@gmx.de> To: Frantisek Borsik X-Mailer: Apple Mail (2.3864.600.51.1.1) X-Provags-ID: V03:K1:ruf67gOjrZmf/gMs2b1/A8XH9rRIR7Vm/tkdLie2W++yshAyAb6 paBUnHr20iDdjRxBO3NAjGkgnwxHWMvWQgRLZTCR/NIwHsLBdmtRYVfJp1lnTHSycgu61l+ +73yDIwvCWy3chQZhOJw2zhXiK8s9GLlARTOYR3V+LDlrX5tfamQhVG7ulI3B36Hsz86eKG c1dyfIc9G0q6En6FBUjhA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:Ud+9Nr49XjY=;rsrsdUKVhzcD1wL/RJDhcMwga39 7GSrGsFU6Pb/crpebbqgjh/IhfhMPJ9A+mebLcz6YzEYr93zmrZIkdvTocUjehpVb40YKoswU pvvk5PGD/jONSR2c0qHLlF6ZB8x+QxfqrKypdv8qKMpFjAgieluMdcNtkU8DmyFupxWSgcsbV kIJrbm+9+llEB4SzNknxqyPu0hPH5aiT/csF6GKI3Ku+jThkUNAikYf8m2NsBY6UP8KwCKsB6 0DH67RCN7+84wWrvU2R7DI+wMdTqENrvqdlC9GaKwF+wwS/+6YHomM6LSd+wK2BiCeoxMeckI ZlusPAq9eEKZFM4raHC2UV0UqL5D/a5jK0LqxjVstO6xPNbGOn8VCSJL38ywD6MAgfpSQ/8nO MMlurJQG1dtHlrMONjm91QgWvJB27G9kI/SzuQuwN5lVX6n8KhK9aA379xVBNFd0U8cUcOPoA USqcoGGrTPKDdi2TiAmI5YXCxpSVCID/on88TMHBYh/F6uFa4cFD/yFyRFDpHNWuRCNUu/Fv3 JHikgY0RmRL665hSoLYyFy1OARmTwcWmMxfvfdooXUnXly+8App3wBBRGw47GAhimwYTe/EYT MWes3860n+GdxAsjSFvAjInRaOt+91hXmh0huzwg/j3PJjoM0WPNFtC651GfyLzWP2hZeV1Uk Y570WKfItQjFgOcuGsa9flPZsvPyE4S9GLtyXyZcnzb88fZ1YYagwt8Egl868S2+uUsXqPcKA iVXqH9uIPZU3H/STYeJeWaI+CEUyB94/Q1OUCYflyx2K7TwsLQN5NudgwtcOERY5dZanjNsVW C/SMZekPVD1SSy6iBjmIY7m1ynDWRM35ukG7bRrNZ8XE3F04QXrwCB2J9KmBp6qxKZh5q4LTF jAFqYdkCDPGlP70Ld8GiyGh7A96QaSQI9D/VZ+luti23UmjhSLHgIDgP1kCOi54vLYf7nYkZi PEH5TZ2cAUrKghf3SC5ZzbWTdsSuQogdDO2kHDXAmE/lQNJoJ6CbQxo1AFRDDxexr+wTFjDMy yeJub5aPDt1wYufpkR+lx/yUzSJ0s1j3wSqsbIYmOJBxzjDemTlnyFk/W31hJmdhGCg8mgH4p ibUmjN2R/mbCJriRP40ZCtsDfy7OoYrsOtD/alySyjdoz8AUyAKsqY7vHjRNioj+O2Ua/bBo0 MYhEmeS7Tp63GTz4cFjzmAN/iV2tE6gpIhihVnORfAIhOnR4m4ZLLkoZyXraDwpa7oI3VQ/lp sL33tCbUnfAxuHMfwtCenL644i6jVj3vfiWjdlaHsa3/0bhluqc1zO3+TMjPzK1qHxXAtRc31 a0m9RxjFQioq/0EphCAAOMfx/8SlleATOdJ2zsQlWEotRISPhIAGYSF2SJTg+gTTbGe/MzT57 twWXUV2x9km6cL7ZEjfDbpmnqcOxDm/bf4TX1h+m2A5Pcljd8YWWpRzMCp6S1aE8OdSsqZM4r GnDxlbvWsIyFoQgoRnk24RCrqwMmT68oz6CI5111AB7K15YFUIHC9uH4z4Rxr21KDZO357cGw C2y4FzegBGtEp1jZb4GbvUGKTeXhV+m2CieB3EmrBUFz9Y5OqaWPGIZRPvAOaAKG915E/WH38 iafVuBFxSvDibtLCFF3dc4nwLANmglidMasVc7vOvuExmgRMkdJSc2S0TwaisW2ng6tkasHS6 j2+J4ZbCu3drK//Be7WeOEUttX6rzBuLmK3TKBYKQFlpyzJaTut5lQqRloeEqkgyMAFED6TEa 0ZepESaGJpxcNt04VUzQTNotCcwRAg5WuwD02gpe1iDYxOyxTFn2J9gTt0ZuJoBybXKU9XDbF KgHjlIiiG5U+Z7ppR+LH9MQB4UomBZ1j17th9UuHiOOMLlgwa1EOO/4RCbdKOQ0Nfh3ztySTE ZcIC41N6w+PvMSPelGbZXwbIPGCmkW4M0vCOBzbBnt4xMaRz2TEwBs6hwkFS1XBf9aJ9FNJJP 1pt7Iiv41FOMtBVSXtf8sxYYFEsXWgu0+TQSNuwHaaxxpthiMtEGS5JRTI+bTZqMNImpXOQzb VhVhq4j33RIKYeEdl+kdlzmf+xA4hzxiIT6yP3MwiXOLaxXrBi4yfpsY+duE9HtZvEOz9fyo1 7GA5cqnF3HL9zs9RC7+vDOaVqYFlccLwV59JQYks1GRPZSm2H34mdyhHgtqK2zN3b1mgqZgFh vQMABrT145NBoAvHbTT2gBorIhMiRJR0+clqGr8vhCtc/McIZx1rljXNvkbZSLoLQVw54EFSQ z7KCNhco8ylPm8Cl07sfIIGHqA6SOLqU4wKYCRAZ3uakulIGgsyZarLuRAEgijV0XNNONiUi+ vfe2wbZR+bclhCirmkHtjJJE/On9yl2BjXnd+xkKPBMJukuT5g7yk6lttyQbc0Os8cR9N62ZT NzcO2Nv+05+juhcMb/NaFTvbhiGJfEOT4TE4UNxPebmFJNKRDIR2sdRsbrS5dsTAbYHULi9L5 tPn7UzJTCJIoy6c+2O7yWk07/YXlfD1ZBWIxQwW0lM654YI0oxRTee/139ZJheBa+uKkOIgDP XgxsvsXZuCEJCw7iYIel9zSns7XpI8mxn2p0P2o85ELJjRGYs2zKnsYReok1bGL69wFu8dr1a MLJikXK2ZTjTB/wDUNVdm4USRrFEv0cWQjsEzB/wpDOsWlygOvIJppk4I/+H3E716JD+wctPV /xgMOlrQKV86k83LhSJdvoRKBtOa4C2MZO7WIaMe+x4QgpEfWTA4NzMM/QOg2jUdrdxhso8ag c0KztGSa1UNwHm+zXetyLexJt/lCs4IN06s1el6QV0ZyLWYnJaetSYIwppiR0NbjUVNuWEZ0d Tq0H84qDZH75+SOjaZzCXxHO2ClWS4m45z3I4XPtXl6AUe6+ZcRjezXRJ9Ah8Nkqy/VcMU2tO Yzd95/3jjtrGg04fGKp53cd91w7s1dG7BeJvrWALUp9I9692Cp4YxvfQBEyH5g8lOLEjd0JIf SxZ8f/pCeMnt2Fi0Htnn0ZIWBEMt7UfjUUMfCstd/dB/SEdT8WUljIurrHGFlqYLUOxyj4SqY Y9fjkWOjF5MCxO4kbDw1PpHNSKpilv8RBl5VWWaFU3wPcPPslgNdw6rVTbxD/5KE4tG2oDmQj VytRp+7EOw+/CKUwZLwrrkaz7VriDmQSB9aoMnboCKTFuluQLes55MaRmT+Wbeld4Py9VARG3 vDdgsVqnfg8HjxjclrU3dBkx8J9GjZakVzYk+iaqIxFdcI21n5WHookmdaJoR2GjQxcFm5m8T a/fPwKKdZwbA+bMpUrz3qjlfJXHe54+Y7rSZ4oYOU3LcdcWkH4yzumm3GYKGRawccnZETVH15 pP/SnAoAM4h8fLNjj4PioCxVnXIMAGQlk6hDNZFIDD54nRoKRfedRDmqx8Txlxei6j68rHJp5 n9beE4yD9qz6OmD0ZFItlX8ag0IspsZ9sPMnWaKLcOeT6UfzL9yCPv3LMyjD9rx2LN3ipD/rL zcTsKX3GinhowjofS0sdKr+2ZNnuZ8+PUN+mqEl1KhaqaEsLXS/nTXkk0QhVqJjzizsYJVFO2 YfTwHtptKRKBkk9t/EtgFZYHO1CHdy7SVr0pQ1vRj9RNLLUAJI8AMJN4xEeq9nf5djMKH288a QPeC49yGremxOsWVkzS07zXSBnSjGUqtb2K+lQfvPTcuNjFTO0x0bfIX2sXQgQ8mz4yKKaT1x qr39AkBidk68Dcez8lixUO+lXCo/JxEu2VhhOHrxSdZXKYbKJRXFDB/E2+LaQnhRrGS8MXC2S NCSxqkWpBrw8N6VGs+6bNMNqVkrYAn0zxoWTc022b2UoQczpPtdsJKaVCfiBSDG7xcdDPkyFM BNievmdRr88rvnKYuMTi5oAsP0XQ4XAzMtJ917bIesLLsa6AQSujSe/9JURJ9MwW30P/c/Ce9 J/xDatafF9TosPhydYG5yRTJkB0wuuBwWfmqgn4lr4jBeKnYJ5RJYaPQdo9S89mPO4/wgighL vo+H5SD4AxnqDvWiuqqjg4nhYzIfaDTAGU0L+Ym2+e6DmQazZhNlCkD7eYscgGc19cdhTId6b V9eFavDUhwdyKH9Qf4LSTimQj73OxzsASV2GdIKhidgc1qgVSRf0TqvI9O+JLHI4OFJm2E9ye PIRdVFOcqFpzoXYOBrRnsPH5U1H4CLkN/cwH/Z3p6lN5/azpKFPejJT1uzkhlbJamuxcixuOX M79MKV+EwSC2t9NCwiPIGSucvjNw4Zt1At/uY1SAcIEOZFACWdyld5Lw/YUUSTxlgBs5pCyye bN9G6IHleYtzufkRe6XCdhc35wOO+189EWnQ0JoAqL7/yR0rbG4RwT8lYxCJnTGb6VSrStLAe UST0xvGOhwsC5HU01rhpVjCN6B4xZc4CHK2OeIo0dXUYHdGUj4WK85mqw3u86Q2K6kbG6+UbQ 6zHrRERyA1IJpgeKEQX4mLI/nMR0ZbE9JQIktakoSz8PDons9e3vp3fUCLMT3ITCeaciEcz4O aqA7zuaTRUpEPrYtoneS5eeO0MT6oZYwOyXTr7yMpxBCpaOTQrnakF13EC/3/ruJdIU1aXrEL Hhb44+m5k2pA5KtDFUIAECTKxA1TzQvJjpTXkBJxpHX3J+7qD4U1aviuJpzWaWeWsi3LzTLsu kq4jmtPaiHPavSRSj3agd/VLg5Gt+v3x8KXhUDpJb3HVTLFbxfjnQ7JavOVWDEevqenMG9p+y +Bf2Y9VQ+DvITmUb+Sb4Uli3dr5UMTzjy/sqPbehEIYNiJOxrnbDpyJUSdrgpT1i9tUB4qwZw JSWULH59EopXJgHE8ZkBTxxgM6fwNYZKt3VX8Msde+WsoWjLy3yEheSyUqmAmGCXxQPHzo5Nr e0h0q0xzkzbbSVksByUWWhI5ev1fc2XcQjdxUwWsZdnMwEiVHQfO7b59PEN3h9fP5cB2QKuxc pUP3e7rEm5hfGXt/bCEs4twPygcYzGFVyPUExUxVa3/sQhh2bbCNEC2LHV3Xq1KX0SO2rwOXN 0+Xv3FanxSjVfCDouceygsglcFPHarpSU+w4KUl1cwrOzYCT1lBKINPG2tNlej7dEgcF0XlLV jDGeOkoSN+fYLXkmpqI90ugDy/ODDCiAmWoqGwu6tKKKUN6EVKLkKdksvg8wIT4Op9vjNy+E5 uf24kXjputNnNQWh/XF5Y5PQqIBOVRQlkC83ohI/9Mcnkp3gMLMMBOTdt8PoLWYi+lNZBl/dC Gv7bhs5Ce32ysepcp57KL4IlHcRKFRcs3fp0nzKcc61+RFTcHYkEept8DzB/1TuCfkRoM4t+e egPFjMNoU3KwCqC3nAnwauuvXR0OoVeYh0Kjh4XXgRtoNvKxXK50xGs05yoj+jWa/jMPSe3RH i7B3qNZiovYUknsqEL/SyR+u62+33fWLPfA5q8IOIUkHE+Q80Ux9jNONNfnV8Ebiiuo5DG1KD c6y3MSJklMCdo3hLG6+N8upgOXjjD1EMIL4tMLQRwWBbTDvPKNW+UGISxz3Y/bm54ixEvR5ow 4rMx1OjeYpctg/JOuivc2KELlI6QqoZobgSozs0DomeVUzmSbmaReM+WQCR665GOkevxDGtlS HEzcV3dTc8/jwnNO0e73WL2eqXNcUAM9m40sJ5Ts25/AhNjVnLuMUrjuJ1paCfaK4eDG2boNy 2wrB8DB7HC1rVgDqp6vzPqJCwfNEWYXyj+Skd/IEEiJ5uQLkUhQ5qNrcMKWx3UO3ie+5knm8m LQCTNac+bV9DFn6IdqPpqIERm+Hkr5LuocnM3Un45l1nh3deGOTA== Message-ID-Hash: BJYJRLLVFZ73BR5UHB4XCEMSBTN6P6KD X-Message-ID-Hash: BJYJRLLVFZ73BR5UHB4XCEMSBTN6P6KD X-MailFrom: moeller0@gmx.de X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list Subject: [Make-wifi-fast] Re: [Codel] [Rpm] Re: [Bloat] Re: [Cake] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon List-Id: Lets make wifi fast again! Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Hi Frantisek, > On Jun 7, 2026, at 08:15, Frantisek Borsik = wrote: >=20 > Before my reply, here is Bob's talk at DPDK Summit: = https://www.youtube.com/watch?v=3DkLdIXVPKT1I > His emails might still have some issues getting in, we will = investigate. >=20 > I will be quick and harsh :-)=20 Why harsh? Nothing against direct communication, but if you feel a = response is harsh, maybe rephrase it before posting? =46rom my = perspective I see direct below, not harsh (so I am not asking to = rephrasing). >=20 > I really don't care about Wi-Fi etc experiments and results from the = lab/home/or Plume-like big testing house even, the matter is simple: Is = the setup run by Dan, an ISP with knack for doing things more good = enough, efficient and with some long-term view in mind, working well, = even more than well, despite all the Wi-Fi scheduling etc issues? Well, my answer is simply, outside of Dan's small (but commercially = important and lucrative) niche Dan's solutions is not a real solution = but a work around... my understanding is that Dan takes care that WiFi = simply is never/rarely the bottleneck, at which point sure WiFi's = built-in bufferbloat problems are side stepped... that is not what Dave = and Toke set out to do in their make-wifi-fast project, the idea was to = fix wifi to have no/less bufferbloat in the first place, and I still = believe this to be the right way forward.=20 >=20 > It is. No matter how good will be reported, potential improvements, = there is no reason for him to scrap his playbook, tear down the setup = that's easy to get up and running, which is also scalable, and literally = chase ghosts of Fi-Wi. Well, Dan, just as everybody else, is obviously free to choose what ever = option he deems appropriate... that is not the point, the point is = current WiFi sucks under staturating loads, period. I ran a test = yesterday at a friends with a Telekom Speedport and a Macbook, so as far = as I can tell proprietary non-OpnenWrt firmwares and drivers on both = sides over 5GHz 802.11ax (wifi6) and once the aggregate wifi rate fell = below the wan rate, I saw latency spikes above 1 second in the = bidirectional part of the libreqos test (the uni-directional tests were = WAN limited).... So the suckage I see at home is not restricted to = OpenWrt's sub-optimal drivers or lack of OFDMA (which for a saturation = test with a single station should not matter much anyway).=20 I consider it totally fine to resort to work-arounds for Dan (and = others) but I would prefer to have the problems fixed at their root, = especially as Dan's solution will not do much for billions of already = existing devices in the field (again, not sure whether FiWi will do = either, but there is at least a chance). >=20 > Are there some ISPs out there, that will fall in love with results = promising a potential improvements? Absolutely yes. There are people out = there falling in love with L4S, throwing away all they knew about = bufferbloat, just to chase it as a holy grail. As you know, I share your dislike for L4S as in my opinion it offers = "too little too late", but it does accept bufferbloat exists and tries = to remedy it, so people betting on L4S are IMHO not throwing away all = they know about bufferbloat, but settle for a sub-optimal solution... = (to me using traffic shapers to work around a variable rate link's = bufferbloat is also a sub-optimal solution)... > There are also people that believes that 6G will safe the day, change = absolutely everything and empower flying cars, self-driving cars and = their home robot butlers, while making AI into gazillion dollar industry = that will cure cancer, and reinvent the wheel. A fact that they were = telling us the same about 5G, doesn't change anything. But what is it from your perspective: wifi sucks and will always suck, = so it needs to be reigned in with additional traffic shapers so its = inherent bufferbloat will never show, or IEEE will have our back and = solve the issues? Because at the moment it looks to me like IEEE's wifi = bufferbloat/latency story is just as over-promisy and under-delivery as = 3GPP's latency/bufferbloat story for mobile. Regards Sebastian >=20 >=20 > All the best, >=20 > FrankFrantisek (Frank) Borsik >=20 > In loving memory of Dave T=C3=A4ht: 1965-2025 > https://libreqos.io/2025/04/01/in-loving-memory-of-dave/ >=20 > https://www.linkedin.com/in/frantisekborsik > Signal, Telegram, WhatsApp: +421919416714=20 > iMessage, mobile: +420775230885 > Skype: casioa5302ca > frantisek.borsik@gmail.com >=20 >=20 > On Mon, May 25, 2026 at 3:37=E2=80=AFPM Sebastian Moeller = wrote: > Hi Frank, >=20 > (I shortened the CC list, I believe the list sghould suffice, no?) >=20 > > On May 25, 2026, at 14:45, Frantisek Borsik = wrote: > >=20 > > Not saying that modern Wi-Fi has no issues or that these issues will = be mitigated at all (let alone any time soon), but compensated with = FQ-CoDel and CAKE, coupled with QoE middle-box and proper peering, it's = more than just good enough. >=20 > I respectfully disagree, and I am not saying this to spite you, but = because I am currently running some WiFi experiments in my home network, = and to my taste it is not good enough. And that is with OpenWrt APs that = already support: >=20 > [ TXQS ]: FQ-CoDel-enabled intermediate TXQs=20 > [ AIRTIME_FAIRNESS ]: airtime fairness scheduling > and, where applicable > [ AQL ]: Airtime Queue Limits (AQL) >=20 > with the following aql twaeks > # AQL Tweaks > aql_txq_limit_l=3D2500 > aql_txq_limit_h=3D8500 > for ac in 0 1 2 3; do echo $ac $aql_txq_limit_l $aql_txq_limit_h > = /sys/kernel/debug/ieee80211/phy0/aql_txq_limit; done > for ac in 0 1 2 3; do echo $ac $aql_txq_limit_l $aql_txq_limit_h > = /sys/kernel/debug/ieee80211/phy1/aql_txq_limit; done >=20 > so from the wifi side this is close to as good as it currently gets = for Linux/OpenWrt with open source drivers (for WiFi4/5/6 APs) >=20 > and still under WiFi-limited scenarios h++ps://test.libreqos.com shows = latency excursions into thte 500-900ms range. For my taste that = certainly leaves ample room for improvements. Sure, when I get closer to = the AP so WiFi throughput exceeds WAN throughput my WAN shaper kicks in = and I get decent test results (with no noticeable increase in = latency-under-load), but that is a work-around only. >=20 > > And it's here, at the our disposal. This knowledge it's just not = evenly distributed and used at scale. >=20 > Again, knowledge is fine, but not sufficient, if I run my APs = under-capacity (that is if my WAN shaper limits traffic rates to well = below WiFi capacity) things look "solved" but the moment the AP is = further away and the signal gets weaker things go pear shaped fast. IMHO = this is not a roaming issue (sure it would be nice if stations would = always pick the best AP) but really a "performance under saturating = conditions" issue that ideally should be fixed, as "never let the WiFi = become the bottleneck" is not a real solution and also IMHO not what = "make WiFi fast" was all about. >=20 > >=20 > > I'm not claiming any special knowledge of Jonathan's work on his new = generation of queuing discipline(s), but I remember discussions with = Dave re: getting into micro-seconds territory. I still do believe that = super smart people from these lists can dig up something helpful from = Dave's scoping of CAKEMQ: > > = https://docs.google.com/document/d/1tTYBPeaRdCO9AGTGQCpoiuLORQzN_bG3TAkEol= JPh28/edit?tab=3Dt.0 > >=20 > > As for 3GPP playbook, not at all. Wi-Fi is getting objectively = better, so all I'm saying is that we can reasonably expect some = improvements on it with Wi-Fi 8.=20 > > This is nothing close to 3GPP B(ritish) S(tandarts) playbook :) >=20 > =46rom my perspective you just drunk the IEEE cool-aid ;) >=20 > >=20 > > Let me share a story. Back then in 2023, Dave sent me to Wi-Fi = Alliance meeting here in Prague with a list of pleas, asks and = questions. There was a few great people from the bufferbloat mailing = lists and LibreQoS customers helping to put it together. And one great = person from Qualcomm got me in, made introductions to everybody and = their mother: from Broadcom, to Intel, to MediaTek, to HPE, to Juniper, = to Cisco, to his Qualcomm colleagues. What I've learned? They are not = giving a flying F about really fixing bufferbloat. For the most part, = most of them, with REAL deal, like baking FQ-CoDel and CAKE into Wi-Fi. = All they will do is some virtue signalling at best, like introducing a = "Wi-Fi QoS management" and other things, which are marginal, potential = improvements, at best. >=20 > That seems close to the 3GPPP playbook to me, over-promise, = under-deliver. That is not to say that 3GPP or IEEE do not advance their = respective technologies, but not in the specific way that we are = discussing here, I feel we are just a bullet point in their marketing = slides, not a core engineering issue (and that is sort of OK, I just = wish marketing would soften the latency claims until engineering is = actually "on it"). >=20 > But see above, the Linux WiFI stack already includes fq-codel and = still performance under saturating conditions is less than ideal. >=20 > >=20 > > We will have more vendors adopting FQ-CoDel and CAKE (and it's = iterations) over time, but other than that, it will be QoE middle-boxes = that will really manage to deliver these improvements at scale, in more = than just ISP networks out there. University campuses, venues, airports, = manufacturing plants, mines, cruise ships, aircraft... >=20 > See, I am in this long enough to understand that this is really really = sub-optimal for variable-rate links. Will FiWi solve all of these = issues? Likely not, but it addresses (some of) them at their root, which = seems the right thing to do. One of the open questions is, will FiWi = actually make live better for the billions of existing WiFi devices in = the field, if it does, more power to it, as IEEE's approach will likely = not help there at all. >=20 > >=20 > > So QoE middle-boxes and bufferbloat, Open Source, communities, will = be saving the day. >=20 > I like the spirit! >=20 > > Can Fi-Wi find some niche use case or help Wi-Fi to fix some of its = inherent issues? Absolutely. >=20 > Not sure this and the sentence before are mutually exclusive though. >=20 > >=20 > > All the best, > >=20 > > FrankFrantisek (Frank) Borsik > >=20 > > In loving memory of Dave T=C3=A4ht: 1965-2025 > > https://libreqos.io/2025/04/01/in-loving-memory-of-dave/ > >=20 > > https://www.linkedin.com/in/frantisekborsik > > Signal, Telegram, WhatsApp: +421919416714=20 > > iMessage, mobile: +420775230885 > > Skype: casioa5302ca > > frantisek.borsik@gmail.com > >=20 > >=20 > > On Mon, May 25, 2026 at 8:59=E2=80=AFAM Sebastian Moeller = wrote: > >=20 > >=20 > > On May 25, 2026 7:43:01 AM GMT+02:00, Frantisek Borsik = wrote: > > >Hey Bob, > > > > > >This is all nice and all, but it really doesn't matter. The only = measurable > > >term IMO we really need is this - is the setup we are using good = enough and > > >delivering all we need? And the answer for ISP like Dan and many = that will > > >come "to Jesus" is sounding YES. It's here, it's cheap, it's = getting better. > >=20 > > Not sure I fully buy this, if I understand correctly, Dan uses = traffic shaping to "neuter" WiFi from its worst self congestion = tendencies... that is a clever way to work around clear short comings in = modern WiFi not evidence that modern WiFi has no issues... > >=20 > > > > > >You will get your evidence and then what? When (and big iF) Fi-Wi = will > > >materialize, we will have Wi-Fi 8 > > = > > > >for those interested in chasing marginal improvements and the = latest thing. > >=20 > > That is the 3GPP playbook, always overpromise for the coming = generation N+1 and once that materilalizes and typically under-delivers = roll-over the unfulfilled promises simply into N+2, maybe add a few more = claims... Sure fitting for the latexstage capitalusm we find ourselves = in, but let's not get fooled by marketing promises and judge WiFi8 once = it exists by its merits/performance, please. > >=20 > > >Jonathan Morton will deliver his improvement on CAKE, we might even = get > > >into microsecond territory. > >=20 > > Last time I researched his deltic approach it looked very much not = going into the microsecond territory, I remember 25ms as latency target = somehow... 25ms is certainly not bad, and not high-latency, but seems = different from ultra-low-latency approaches. So I might have missed some = interesting development, if you have a link you could share to get me up = to speed again, I would be grateful. > >=20 > > > There will be FQ-PIE, PURPLE CAKE, HTB-MQ (to > > >supplement CAKE-MQ)... > > > > > >Anyway, you will like this: > > = >https://arstechnica.com/gadgets/2017/02/going-hands-on-and-behind-the-sce= nes-at-the-plume-wi-fi-hq/ > > > > > >Plume used to do this, you will have your Fi-Wi house test bed up = and > > >running, soon. Let's have fun and do another round of the good ole > > >Wi-Fi/mesh router rumble: > > > > > = >https://arstechnica.com/gadgets/2016/09/the-router-rumble-ars-diy-build-f= aces-better-tests-tougher-competition/ > > = >https://arstechnica.com/gadgets/2016/12/review-comparing-google-wifi-to-o= ther-mesh-networking-heavyweights/ > > > > > >Maybe Jim and Ars Technica would be interested in it. > > > > > > > > >All the best, > > > > > >Frank > > > > > >Frantisek (Frank) Borsik > > > > > > > > >*In loving memory of Dave T=C3=A4ht: *1965-2025 > > > > > >https://libreqos.io/2025/04/01/in-loving-memory-of-dave/ > > > > > > > > >https://www.linkedin.com/in/frantisekborsik > > > > > >Signal, Telegram, WhatsApp: +421919416714 > > > > > >iMessage, mobile: +420775230885 > > > > > >Skype: casioa5302ca > > > > > >frantisek.borsik@gmail.com > > > > > > > > >On Sun, May 24, 2026 at 11:57=E2=80=AFPM = wrote: > > > > > >> Hi Frank, > > >> > > >> The question needs to be framed in measurable terms. > > >> > > >> The systems you named operate at different layers than the 802.11 = MAC/PHY > > >> layer where TXOP allocation, retries, EDCA contention, AMPDU = behavior, and > > >> airtime utilization occur throughout the building. batman-adv = routes > > >> between mesh nodes. CAKE and FQ-CoDel operate on IP-layer queues. = QoE > > >> middle-boxes operate from the WAN/IP side. > > >> > > >> So the question is whether IP-layer AQMs or WAN-side QoE systems = affect > > >> measurable 802.11 MAC/PHY behavior under load. > > >> > > >> If they do, the predicted MAC/PHY effects would include: > > >> > > >> - lower failed TXOP percentage > > >> - lower retransmission airtime fraction > > >> - improved AMPDU completion efficiency > > >> - higher payload delivered per TXOP > > >> - lower AMPDU truncation frequency > > >> - reduced EDCA wait distributions > > >> - improved airtime utilization > > >> - reduced service-time variance > > >> - changed MCS distributions across stations under realistic = spatial > > >> topology, particularly at coverage edges and where multiple = APs or RRHs are > > >> candidates for node selection > > >> > > >> That is the measurement gap I am pointing at. The industry has = extensive > > >> 802.11 feature lists and marketing claims, with comparatively = little open > > >> tooling to falsify what those actually do to building wide 802.11 = MAC/PHY > > >> behavior under real multi-client, multi-AP load. > > >> > > >> I developed and still maintain iperf2 because throughput alone = has proven > > >> an insufficient measurement model for network behavior, e.g. = latencies and > > >> responsiveness under load. Features added to iperf2 include: > > >> > > >> - trip-times > > >> - bounceback testing > > >> - one-way IP packet timing measurements > > >> - packet-level latency histograms > > >> - message-level (TCP write/read completion) latency histograms > > >> - responsiveness under load measurements > > >> - enhanced per-interval reporting > > >> - CWND reporting > > >> - RTT reporting > > >> - bytes/packets in-flight reporting > > >> - TCP retransmission reporting > > >> - TCP congestion-control selection (CUBIC, BBR, Prague, etc.) > > >> - udp-l4s including CE counters and durations > > >> - isochronous traffic generation > > >> - socket-layer pacing via SO_MAX_PACING_RATE > > >> - token-bucket write-rate control > > >> - Markov-chain packet-size generation > > >> - UDP latency/jitter analysis > > >> - multicast testing > > >> > > >> Those measurements operate above the 802.11 MAC/PHY. The missing = layer > > >> remains open 802.11 MAC/PHY telemetry, which is what I'm building = now. > > >> > > >> This measurement standard should apply equally to any claim from = any > > >> architecture, including Fi-Wi. > > >> > > >> The question becomes: does centralized MAC telemetry and = coordinated > > >> airtime control affect measurable 802.11 MAC/PHY behavior under = load > > >> relative to autonomous AP operation? > > >> > > >> Measure the same MAC/PHY metrics under equivalent topology, = offered load, > > >> and client mix. If those measurements do not improve relative to = baseline, > > >> the architectural claim of Fi-Wi fails. We won't know until Fi-Wi = is > > >> designed, built, deployed and measured at many different = locations. The > > >> theoretical case is strong. Centralized scheduling, joint = optimization, > > >> and observability all argue for it. The design and measurements = are the > > >> next steps. Then we'll see based on evidence. > > >> > > >> Bob > > >> > > >> Technically, Betamax was superior to VHS, and yet... > > >> > > >> If we would be talking about FiWi pre-jump from Wi-Fi 5 to = Wi-Fi6/E/7, I > > >> would even try to do my best and ignore https://fastgood.cheap. > > >> But we are not there, for better or for worse. > > >> > > >> ISPs like Dan that use Wi-Fi 6 (with mesh, especially based on = batman-adv > > >> and FQ-CoDel / CAKE) and above at customer premises and Quality = of > > >> Experience middle-box on their last-mile, while providing good, = personal > > >> customer service (not some crappy outsourcing of it to India or = "AI") will > > >> be hard to beat, even for a big telco/ISP offering cheaper price. = Yes, some > > >> people will leave but the most of them will be coming back. > > >> > > >> This is, believe it or not, not a high bar to jump over, even = though not > > >> many ISPs are getting it already. We all know that more or less: = "Bandwidth > > >> is a lie, Bandwidth is dead," so it's coming. They will be = throwing more > > >> bandwidth on it for some time, but we will be getting from = "innovators" to > > >> "early adopters" soon and then, all we need is just that = "crossing the > > >> chasm." > > >> > > >> Despite all the difficulties, it will be faster and cheaper - = also "good > > >> enough," than FiWi. Or rather, it's here already, it's just not = evenly > > >> distributed. > > >> There might be some good niche use case for FiWi, though, once it = will > > >> mature and get there. > > >> > > >> All the best, > > >> > > >> > > >> Frank > > >> > > >> > > >> > > >> Frantisek (Frank) Borsik > > >> > > >> > > >> > > >> *In loving memory of Dave T=C3=A4ht: *1965-2025 > > >> > > >> https://libreqos.io/2025/04/01/in-loving-memory-of-dave/ > > >> > > >> > > >> > > >> https://www.linkedin.com/in/frantisekborsik > > >> > > >> Signal, Telegram, WhatsApp: +421919416714 > > >> > > >> iMessage, mobile: +420775230885 > > >> > > >> Skype: casioa5302ca > > >> > > >> frantisek.borsik@gmail.com > > >> > > >> On Sun, May 24, 2026 at 2:12=E2=80=AFAM dan = wrote: > > >> > > >> > > >> > > >> On Sat, May 23, 2026 at 10:36=E2=80=AFAM = wrote: > > >> > > >> > I don't have arguments on the technical bits of your reply. > > >> > > >> The industry hasn't provided open source tools to analyze 802.11 = properly. > > >> The proprietary ones are tightly coupled to chip firmware, owned = by 802.11 > > >> vendors, and not for sale. > > >> > > >> You've built solid networks, especially given how little 802.11 = MAC-layer > > >> and MCS observability current tooling exposes. I hope to make = open source > > >> 802.11 MAC telemetry tools available sooner rather than later. = These will > > >> run on both an ESP32-C5 and an RPi5. The inexpensive ESP32 allows = monitors > > >> to be placed throughout a venue at low cost. > > >> > > >> A key issue is what's being measured. Your deployment data is a = capacity > > >> analysis. Once baseline capacity is adequate, user experience is = driven by > > >> tail latency and service-time variance rather than throughput. A = network > > >> can saturate aggregate throughput while still showing large = service-time > > >> variance and long per-flow tails under contention. These are = different > > >> measurements. > > >> > > >> And CODEL and CAKE are IP-layer mechanisms. They don't operate on = 802.11 > > >> TXOPs or airtime sojourn, which is where the contention and = service-time > > >> variance actually live. AQL is closer. It operates on airtime at = the > > >> driver/firmware boundary, but it's still per-AP. There's no = coordination > > >> across APs and no MAC telemetry exposed upward. > > >> > > >> Slide 6 of my DPDK Summit Stockholm talk lays out the layering: > > >> https://www.umbernetworks.com/DPDK_WiFi_Stockholm_Pres.html > > >> > > >> Check out iperf2's advanced features around --bounceback, = --trip-times, > > >> and --histograms. These are available as open source. Man page: > > >> https://iperf2.sourceforge.io/iperf-manpage.html > > >> > > >> I'll try to respond with some metrics soon. My rig is down at the = moment, > > >> so give me a few days. > > >> > > >> Bob > > >> > > >> > > >> I agree. However, I'm not actually just measuring throughput, = but running > > >> latency sensitive applications without issues. Frank might = attest to my > > >> efforts to reduce latency and I routinely share data on lqos (and = another > > >> QoE product's) TCP measurements for latency and among QoE users, = I believe > > >> my network is top 1% in latency and jitter and in the WISP space. > > >> Obviously I'm not going to compete with XGSPON operators.. = (though I'm only > > >> measuring TCP because that's the 'easiest' to measure passively > > >> practically). While this is not an engineering adequate = benchmark, if my > > >> VoIP handsets work over wireless then the wireless is good is a = very > > >> reasonable latency, jitter, loss argument. And I run a few = brands of WiFi > > >> based VoIP phones (Fanvill Wxxx series, Yealink Wxx and AXxx = series). > > >> Similarly, if the sonos works and is in sync, the wifi is good. > > >> > > >> As a service company and as a user, I don't really care so much = where the > > >> goodness is in the system, mac layer or IP having cake work it's = magic. > > >> Basically running an AP on OFMDA (as much as possible) and well = under the > > >> 'red line' capacity delivers great results on WiFi7 radios (and = some WiFi6 > > >> radios). I have no doubt that FiWi could get more of the = theoretical > > >> throughput delivered at the mac layer. > > >> > > >> Deliverables are all that matter to me and I think to buyers and = users. > > >> Benchmarks test deliverables which is great and I'm a routing = iperf* user. > > >> It's engineering's problem to develop the next tech *AND* solicit = funding > > >> to do so. > > >> > > >> > > >> > > >_______________________________________________ > > >Codel mailing list -- codel@lists.bufferbloat.net > > >To unsubscribe send an email to codel-leave@lists.bufferbloat.net > >=20 > > --=20 > > Sent from my Android device with K-9 Mail. Please excuse my brevity. >=20