[Codel] Re: [Rpm] Re: [Bloat] Re: [Cake] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon

[Sebastian Moeller <moeller0@gmx.de>]

On May 25, 2026 7:43:01 AM GMT+02:00, Frantisek Borsik <frantisek.borsik@gmail.com> 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.

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...

>
>You will get your evidence and then what? When (and big iF) Fi-Wi will
>materialize, we will have Wi-Fi 8
><https://www.linkedin.com/feed/update/urn:li:activity:7460998580456116224/>
>for those interested in chasing marginal improvements and the latest thing.

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.

>Jonathan Morton will deliver his improvement on CAKE, we might even get
>into microsecond territory.

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.

> 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-scenes-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-faces-better-tests-tougher-competition/
>https://arstechnica.com/gadgets/2016/12/review-comparing-google-wifi-to-other-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äht: *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 PM <bob.mcmahon@umbernetworks.com> 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äht: *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 AM dan <dandenson@gmail.com> wrote:
>>
>>
>>
>> On Sat, May 23, 2026 at 10:36 AM <bob.mcmahon@umbernetworks.com> 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

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