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.17.22]) by mail.toke.dk (Postfix) with ESMTPS id 27A371165779; Mon, 25 May 2026 15:37:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1779716225; x=1780321025; i=moeller0@gmx.de; bh=I7V4lPg6gcAiLDUWJj/WVh5guy6SZIMCYnFoZKBjZYg=; 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=m2qRC5e3z5eMtDLWw7Ih01d3iKuBKk2rxLlhLOvSl+bcxKfiC421MmKRZyH94pl1 4Ybp2/p+X968yUqkVl0Jr9sCyjEpwWh1IzqBZo6i7ak38M97956sXyQxJRIZsW/RE k6KGb/RWIO05ZuFNpIEVEourZtV1MRmVz3QdOXkF7NBrHGrc+sTffg9Fbcp5ksENQ ZJvQuAoRQzCE4jVZ/rIC3WyaOKXcXavxgtSiAFc+IlNHU4wjoDA9dLJOjtjQ8Lz40 nWyNYE9Ausb/Bh98+e+aifNNu0Sq1quU54TocfpPeKRF8kgilM9GqMO3uzfYitL55 xJ3oicuZVd2wS1Y2wA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from client.hidden.invalid by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MybGX-1xFLOX3E33-00s0Fu; Mon, 25 May 2026 15:37:04 +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: Mon, 25 May 2026 15:36:53 +0200 Cc: codel@lists.bufferbloat.net, bob.mcmahon@umbernetworks.com, dan , Cake List , Make-Wifi-fast , bloat Content-Transfer-Encoding: quoted-printable Message-Id: 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:wzTkm15IQZjFAAmMD7vYy1l4IXzEniE+Pmy5BR+Q+NBTrS8lVzP SuiBm/kwdf6x5uAYMKRO5iiX+3rSB7xPrOLpxsx6q3wqNyAJ4e8N0504/c7oU6JeLuQX2pj m3cfExBS2ZBhPyVFK+95VPot6UQmdMeVXw0bJ+Dj3YjjdvsrxJiqDf8XjzsGqmpsqPiWfhv 4WhBTQ215FRgbrd8FqJcg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:HPx0DVo1oWQ=;sMFe8pmcHXoS52hCaRObJOmK7Mo /j5Gy4mWvpbzDxLcn+Iutl48vGTDoh5kpDgpJTzCNudHYlDnMPvFi1e3i8V8VZb4GQsHLDkrl BaYjdGhV9mqu6gEuGphPI8Mq04CyVJNoHIKxawc8x2d2cuQyVrJIqxpGkZf29X0FxuN43tJ1b SQ7SoezuXAKkIqf3EWvfNPosB66+jqPfLShQRc+a438wKMoCxyh6d3G9Sr+iCwQj82LfVWraB TW85Qjb5OT5ozwWstnjddQLKn4EWQamjaHOdpkkPZOXIjcrM98xO9rzlKwA4nqZ971gNbIEoF 3qokz4jAtJTQ3uoG4PCFYH/zzxPsU4/kzSRQiqv6klM69t51NMAhMoqv+r2P3CdefOnbTx6gy ouXwRI+sowSRvZq//GTWR2qUtucB/qfgkVU9/GVlweBB8yHVHhlxVuRFxeMaTpzaXQNCUoovf XIBkaKEjN2WBFIFjAGodIDHcarkHPWmcMWIsLTBI+anu3JJgs1+e0BW3fxk6a+aM4ZcWgvynW xOS7EyA6B55N2mThYchajF+gjB16nrFnVU2gMTWbYamrKQJxw2vXZR2ow7x4oK2dpJ1V+f4yE ERWIHpmAtF+Mu2Somz0YATxwk/VVtwkpU8JMBBBmHoH1whUksVifHKRBN46meLPCkbbNHwsx7 YBQ36+CqBkcQud/W/VkiFewy1XWp52k07DxxfWHxgwN1xyX2BSzQioLgEEB9irlFy1ippuC+4 7wKlxKBUumR/AocHq2jEFAr3hiy+4Mx7I2v0FV7B/XCCzpKf3KKkzkdSrfjh0rFecB5Cw8fvF wUwzhepgucbBE/bhO4PXmf9JP/OUTnZIiuhH75IMYYcl99econDl1lbb6jnXzxjFhIitJh1oU M3ZcXPqFvT08I6H1CFji37LgpJnmRx4rxen1O7xpP1qrFKnJLSai0cHg+bUf7gmv3RMJ5AZsh lgdpEeP7kgtYOu6FdxcuVNRm5G27ABIk6iTwGfVzJKtdc1cFK8maKvMqG93KkrBt+ooXXlVyT p2hkaIcDQBnYd0GIZv0QXNz1hrAvrn7iG3qGM1vvu+YPLMJmUgfp9ARHHmKNEk98oDA+AD+2L IJoOK04LsRlrarg82mVMtHStRIASW3iCmzFW0MgwLAJQsQSse1m63giJcAM2Z2/M68kqA/p1y XXHJ0hUExs75/og0PXLsEoYG3fe4PRe9dLqTBFwJW6bwinIeRZHmrrj9wa7q98TESmxXCB7Jq yGN4GACMBV65+xZrMYQk2ds4G905+084vj50ego1z2ynrXMOMNbxe+V5gpvhXGD5w2UuIlQIb cGrHS7nQIYA9FSzRcMUen6Et/BQEz4WB6revvFj0CovMIzbUYi1eqCpqjkQL6PZBGGEk+o2/K jkxZqaTICpmWQtTAhI/C55r7eJcEIZiwF0aHimxITvoDooPV0G+4Z7gDEmlUfCv5kmQwaXkP8 rGCb5t4gr4o/kIUBl8g9gRyJXm97QH5BMCLphiWDfZ8XsrDsmUHye7emC0Th44PvCyrR2ZMdq o6hfRp+T+CHwF2UOdpZ/cuAtb8ERo1IXAh0FGP7YW3Jr7135O2w/N/cbEzmgPLj4u8QpT4S3D CcWaM9xNmxAnuXCH2tTHMraQHLR6GMBPfoUIMjR7J3+VKJml76JiC4YXrwUJKDox1sJBMHPIi v7uThBl5SPEtA0WvjIGZLFtqp3+Hky+D8jAYebs0EqmIyqKAXATtN2azNu5mD2SFDvUJe5F1R 40KgSRF6e/6q0Jc+7aCB0xWc3hsl+dIVUTNsLpyWAZrRZvue6ShVRO68DyXM1NAYcpNtoXe9y Q/hZWoF2oR5ZLO+vxsswZWqaqB4GFy6mcpSReVFdZD4646JDQrpUVp5WiEEwFJsRr+oqmuFI9 cJU3bSjHFXq0afoJinzq7z0mMpLh9hoT3PZAYzDNwCfk0XhMp7tamwwrJPTx0TBy+QVl0Q8id YFDD3h23i9r0giWQ4cD+abgZ4PPHGCJKbwsnFIDx8dlUR7pJ+dH6hyJq4RRpZH22JmstkCyY3 WrLKx5WnhkdMpqV3RYw+tLO+vT5Jhn9dZUR7FdbHeVSste+CZg5FQvpfxuO+eFyOMwvBvzH9x hmH4cm/2TVV7Jw5OhKHzI+zEcEvTBd8Nh36jleg2xm73gP7/tk6Vm0COiwy5rENX8fM08J2dp FOmaTZkGzG538cooP5bIs5MGt5ybmE8AgI0C4V3O2HJoyYW8WDUX42f7uANveyisbfgahMZcV +Ewv+Vguo1zkH6pkWVlELJqtDjbgxf81LgaO3gRnSHwJ6QCkF6KdH5IJ2lLZ0Cb1zRi7etWR1 7btnN+XhGbqhVge49gdx5kd9K6Vmf2Xchiri5HwMIzJbyWnPCDJLPtKptHUe/iVstK/GzqXoj 9R3uVt6sapYLUyn9dgN2G9hpC/OEGE3+BHnqwlEOmJhVflEVA4zD6tU9wVPc3iko9rEpyaao9 ZSUABBBNhaKukSrJperSq3NC4t28cx6xIBjtf/r4Uzyxs/b6LBVn7Ont70PIxmFGThcz+G4Sn 3LwF3D3jETUGO7TL13tEEiX+RejSMu6yBhE+2bTNsFWv57nReYfjy4YSDYO7iBsZKeDzq4qaN +qxqZgqdDl22AbJo6y3Cr0c5rrWCg3/8RMDhxL9BEIkkh84/P91OZRm31nQyNXuMyt7olD6mI 8+ZtUNsp213FywuJisFVAe51CssgW06qmx3mNvhMGdla3ATFxW+sz7TWQK7CopCfHViCsgqgq V8G5rhTXlG6IMuQfQKrNuaRRJAK9IDGrzAvTFpPuSRdIRMP4E0Se6q6lI2lh6TWyXfjlYsW0m Tx0ecB/nsUWvo5VvgvV2lCrdBpDH02rIYbso/KOCFcSL42FyjtsZk5Wd+a9biCY/GsQibV7pa qm/DQ8qarEYxELy+eT3BiQO/FIQPBKiYZUFaNW4z4EFFjuR6mHqH8T8vZ5J3DiRRLS5fXCWo+ GIOuQ3SiMGsfjE1IBuToTvA7KiZKLE90st0FRJI/hLyuO50h4L+k2ysqGMJt4+Zuf/P2ips8L 64vkQlsfnlhXSATbKnFlDJqWM+trgrDVVZ5NT9LbOV6HFwKSHNIpXfx8maMdKFUIdi9sJ/pFw /5J+/nXgVUwavEEHi/ToAkIrtsOfEcRidN6SWb5Zoa/ymsiMuIgwrJQkcR2K43i9JpUmW5+XL AllRi22CMIbAEM26dqG5IGrS7dDFcKU/CHwCoXHp3m4eNQmYS++z4+/jfgFqP+U/eoZQZdEZw CaN0h0QqUC8GmianzMEtUET9+yVbtO0pvgSb0U9BynRwiG7kR2aa3a6HhxUw4vGMEc51xe9Ig kz/FjYGHr9dcwXntOSa6syARb1PH5EguaSbZL5JGkfIytsdlzJgKDOqYjH4bbdvvYWAjfexdS N8+aqn7kFCjHGa/RHMdS6335WS7fjOYw9cKZz6Dxnw52lveyCYwNIF6QDWszQNfBbp9Z6WljG 6J7EUJbdbHat/oFuUSnbBT44e+Pge76DgFpvGJGWvDzWnUqV8gPakE3kjmMJyQS3gE8uilObd xE96vMlx1WBdTE4AimoGxcXm+LWN5utJ4xbjNvv93Gtxu3Au9X8S9HxPVhYFwaf3ICnNHbHp6 7bEOzys45zubq4TeRQbj/J6Pg+jbfeAtXM+iIY1TaMecOFu3TADbEOYxnDvrJtFcpFDtGFlPR yNA2o0hpBMNk7ceGDXIMPJPgtUvNwzw7aks+/Y/zfNCqjE3Cu+b1Elcj6P/HbAqSwTbWZm6oI b/57KamUNnx2/OkMij+wI8+YSm1pOIHvKHGvfz5SG/xdgApwuUTQHi5k8YXacmHt8adbf+QQ7 Lsyc/z1tH2QZ0AdP3665OlqeERLbWQnaYQCH42fpdU+01tKEuem37Y5nmVvEPiqovZ5b19KXq PxGMr2gKuRyt5rth5lHsaNNsLyAQaalaDFfr17EQv/Lb2Dcfy8as6U0CoKl2okX361WKz993T 24Fb5eKFxChNq+OZwC0/3eo7d6MU+ePZ9ZLuOT/b3GaNLpPyAGLOXJKkDJY4Lfs/CeWI26h2G 8dhLa5+H0prRENUlYUaP+KOyS2jf8TLKxNemsy+d8rVlLHa17XfmgfkwKW7ZIJCBBmueT9I0r aWCQ6KWIck3TMVHqHMArSkVe3LAHDY7x+sJ8XUXRZwiKQBL3WQ2f5TsQc05eYfKhWludn7osD qAoQ5aCRMP9VS+kL83WzG61lxcgw2HCR1EPo3sg3x6L55e6OhEZA5Ree8jJFaHN3BJ5Degeje uZ/7KSv/6VsjbwjInWQkCWXY64bltzNCNBwQ/P2JEwFl92aXHjRiwSBnWiMLVD3fMrqUHhABP MbFAGdw2LHQbo3YAL7/hV8YkouVbj7WrsX32eHAvRXE2hZMiDR3h3AEfj6Tz319F3eXQT3B+X GzHMvsoa25eCBV1wR1vF0mxYc03kSjvNPMHV79H7K9+PU4B2biK6p4M88j134si5GPiOuEEtJ he+au+T//h1JQ+HXwUvqZdxriMnHFal+qt5UqmYr7zGNLeRlz8iqDSN6igWlN7p6+RynmTTMf 9+dWIP842x7iuJrDwek8m/rQWplWyQJ+5j0GjIPJP4c+iVf8fHhaLvc06tFXm7U//X7LHumyb R6on84LqkoW2zSPvobUPRiWll3tCMFMjm3KV/oVMxNSRWpjYqGeBYTClm234zPCQExPHqEItP vDhfZjWxKSVNusdnAohiuCUhA3iXKxHr9OY1TjrNquf8pxH2o23CC19mgIgUPNGO5AvZbkeL8 H75eAiMfF0GT1OwGtt2SFj77GPStCZbaLIbAD/uN2zO41G2RmGME3inHE3ZAVffz7ep2E2EXM 4S+9ZHfJc6uI+s4Y+ZiWA2V+5+8N2T63KaSuWGwV4QUu0adsB3wm0CfJ5A6rM9zZbFeP8hv0I CEY5CHF7JXO/v6VY7Y2nkytSS5oZEsi7Wh494GHANKyoCveKu8JAnnX8apZg7zLuSxyfT5A01 3DTHB4Drez9AlrvBep5lJfRlVOii5Jps9dpMnK+A6Tx9KAaMFxflbcCKuggWPF9XRedHSo4Ya 12huLeHuzbFsOz0xHMr1TFusAWTkFj5R07Zr7F0orySWdPZIb2AIsb872YetlCZicl+VmQ1l2 MnUHXf50m1KvmW3sALnFYsMlXd6WgZ4WKA4Xs5qPxE85/m4w+Ez4o/AYEFdlnDigONZ2Da6u1 J4VdkQlDhs4YKb39Qp915KYCgK1GJnFRl9hjsgCdvBr5rAkA+J/FvFV3k9IO/XtWv80j0+g/G HI6uPCzs9zCbyPVVs2ThrzHn2uupaq46P3XHCJaNfFY53vOHSKSYWYgaAcc4odwpu/Q1K4vdE 2C4KtfgwwpkQsFgcANellI7ch3PSY2iN00SRNbGNSYlqU9046/YWUXtnYTQm2Mm9iW3NQBHQe t2x8y+d7GijwgGKp6MgPRV/jwsJQ49+zVrUvgi8fkGT2itlyMs+14fLiGLstYzNr+zCLkWbnj NgLcifCij7P3OHJ8C/kseHJm3ODsaK1mMhPVGKTwuAi4jy0yoi2NfqcmLrpw9GGPOBWvgiKIK 01xEcUc5eB74qrGoKIli4u+ZFjHtbrA26+jujAaPR2kKYHjj08IkodL/BbbVbDtKeFvGrQ+5i g7czJngROWcKXhzSUVGx35FhYYE/nuQPFB5EGGAF3RUELlS+ZTMhhJv2g5TTWw57rtko+J2Ib 6hxHtMcX4gNqvufdUKtg9CuOiJaIuh2SAym7uxxPA9OwuSDcgVv26wNipYiBrX7nAECBqAg26 ACx6GqrTGY4flg2hWe46g Message-ID-Hash: F2OXZOYXG3EPCEUIINCYDJHTIDMSE4EL X-Message-ID-Hash: F2OXZOYXG3EPCEUIINCYDJHTIDMSE4EL 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: [Cake] Re: [Codel] [Rpm] Re: [Bloat] Re: "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon List-Id: Cake - FQ_codel the next generation Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Hi Frank, (I shortened the CC list, I believe the list sghould suffice, no?) > 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. 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: [ TXQS ]: FQ-CoDel-enabled intermediate TXQs=20 [ AIRTIME_FAIRNESS ]: airtime fairness scheduling and, where applicable [ AQL ]: Airtime Queue Limits (AQL) 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 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) 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. > And it's here, at the our disposal. This knowledge it's just not = evenly distributed and used at scale. 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 > 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 :) =46rom my perspective you just drunk the IEEE cool-aid ;) >=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. 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"). But see above, the Linux WiFI stack already includes fq-codel and still = performance under saturating conditions is less than ideal. >=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... 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 > So QoE middle-boxes and bufferbloat, Open Source, communities, will be = saving the day. I like the spirit! > Can Fi-Wi find some niche use case or help Wi-Fi to fix some of its = inherent issues? Absolutely. Not sure this and the sentence before are mutually exclusive though. >=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.