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

[dan <dandenson@gmail.com>]

On Fri, May 22, 2026 at 10:36 AM Robert McMahon <rjmcmahon@rjmcmahon.com>
wrote:

> Hi Dan,
>
> Thanks for this response. These are things the 802.11 customers and
> operators are being taught all over the world. But after 15 years of
> testing Wi-Fi chips and maintaining iperf2 as open source, I see things a
> bit differently now.
>
> I find there are generally two very different ways people evaluate high
> technology.
>
> One is marketing-driven. The goal is feature lists and numbers. For Wi-Fi,
> things like peak PHY rates, signal strength, and single-client benchmark
> numbers. Then Wi-Fi 6 to 7 to 8. Whatever closes the sale becomes the focus.
>
> The other is engineering-driven. The goal here is to measure what actually
> gates performance in real-world environments. Real-world conditions matter,
> and well-designed lab tests rarely capture them.
>
> But this raises the obvious question: what defines performance? A capacity
> number on a retail box? The end-user experience? What defines that? I'd
> argue latency under device count and load is a major thing to consider.
>
> Once performance maps directly to user experience, the gating variable is
> not RSSI, SNR, or PHY rate. It is MAC behavior: TXOPs, retries, contention,
> queueing, aggregation, airtime, and EDCA dynamics that determine who
> actually gets transmission opportunities and when.
>
> This reveals a major measurement gap. The common tools mostly expose
> PHY-layer observables such as channel utilization, noise, MCS, and maybe
> retries in coarse form. They generally do not expose the MAC telemetry
> needed to understand how the system is actually spending its finite TXOP
> budget, why airtime was consumed, or why behavior changed under load.
>
> The achievable TXOP budget is finite, 10,000 TXOP/sec (lesser per
> payloads) Performance is gated by how those TXOPs are allocated, delayed,
> collided, retried, aggregated, and consumed across competing stations. A
> TXOP lost to a packet error burns the AMPDU with it. One failed TXOP can
> delay 64 Ethernet frames.
>
> EDCA in deployed systems is mostly static policy, not a globally managed
> real-time control loop. There is no building-wide BSS manager continuously
> adapting EDCA parameters across APs and clients based on measured airtime
> state, contention behavior, retry burn, queueing dynamics, or service-time
> variance. Autonomous APs make local decisions from partial information.
>
> For example: why did an aggregate stop before the maximum possible size?
> Queue starvation? Retry pressure? Airtime expiration? EDCA contention?
> Firmware scheduling? Coexistence? Driver latency? Another station winning
> the TXOP? Most systems don't expose enough MAC telemetry to answer cleanly.
>
> So when I hear the argument that modern Wi-Fi has "basically solved" this
> because OFDMA exists or because Wi-Fi 7 added another feature, I hear a
> feature-list argument, not a engineering driven measurement argument.
>
> OFDMA is a PHY-layer scheduling improvement within one BSS. The trigger
> frames that drive it still ride on EDCA, so the "scheduled" uplink is gated
> by unscheduled contention upstream. In dense multi-BSS environments, that
> contention is exactly the problem. It doesn't provide global MAC telemetry,
> deterministic service intervals, or building-wide scheduling across
> autonomous APs and clients. Those are different problems at a different
> layer.
>
> That's the gap Fi-Wi is built to close. Measurement and control of actual
> behavior across a coverage area as a unified scheduling and timing domain,
> not a federation of autonomous APs each guessing from partial information.
>
> This is also why L4S is critical. It's not just for transport. It's for
> wireless too. And wireless is now driving user experience.
>
> CSMA/CD got rid of collisions by being replaced, not improved. Switched
> Ethernet eliminated the shared medium. CSMA/CA is in the same place now.
> Hidden nodes, retry pressure, and EDCA contention won't be fixed by another
> generation of contention rules. They're solved architecturally. That's what
> Fi-Wi does.
>
> Bob
>
>
>
> On Fri, May 22, 2026 at 4:10 AM dan via Rpm <rpm@lists.bufferbloat.net>
> wrote:
>
>> On Thu, May 21, 2026 at 1:36 PM Frantisek Borsik
>> <frantisek.borsik@gmail.com> wrote:
>> >
>> > Saw this one from Bob on LinkedIn - maybe there is someone interested
>> lurking here...:
>> >
>> > "Umber is looking for a Bay Area cable tech (contract, part-time to
>> start) as we prepare to ship our UAX-8 concentrator.
>> >
>> > Each install uses a hybrid cable: dual fiber for data plus copper that
>> powers the remote radio head. The job is to cut to length from a 1000 ft
>> spool, terminate with a pigtail, and verify optical power and low-voltage
>> delivery before units go out.
>> >
>> > The Meta Level Up training is free. Umber will provide the splicing and
>> power-testing equipment. First units and our power distribution system
>> should be ready by late summer."
>> >
>> >
>> https://www.linkedin.com/posts/robert-bob-mcmahon-b1a42a1_levelup-fiber-technician-pathway-meta-data-activity-7463251969630097408-AcWJ
>> ?
>> >
>> > 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 Wed, May 20, 2026 at 12:45 AM <bob.mcmahon@umbernetworks.com> wrote:
>> >>
>> >> > the reason home wifi is so bad is because there is no coordination
>> >> > between the wifi in the diffeent houses/apartments. you don't need to
>> >> > tie all those devices into a single network to solve that, and unless
>> >> > you do solve the coordination problem, there is no way for you to
>> make
>> >> > the rf environment better.
>> >> >
>> >> > coordination may only be an 80% solution compared to this, but 80%
>> is a
>> >> > lot.
>> >> >
>> >>
>> >> David,
>> >>
>> >> Even granting the 80% claim, which I don't think holds across 134M
>> >> occupied homes in the US once you measure broadly enough, the loss
>> >> functions shift dramatically with density, workload, and metric.
>> >> Throughput, tail latency, and jitter under load do not degrade for the
>> >> same reasons, and they do not reduce to a single number.
>> >>
>> >> Even inside a single home with one AP and no neighbors, Wi-Fi exhibits
>> >> pathologies unrelated to cross-network coordination: hidden queues,
>> >> retry storms, aggregation bursts, EDCA backoff variance, roaming
>> >> decisions made with stale information, and firmware behavior the
>> >> operator cannot observe or control.
>> >>
>> >> ECN marking, L4S, pacing, and AQMs all assume the layer below them
>> >> provides observable and reasonably bounded service time. Conventional
>> >> APs do not provide that. Coordinating neighbors does not fix it.
>> >>
>> >> The deeper problem is architectural. Conventional Wi-Fi scatters the
>> >> observations. No AP sees enough state to make globally correct
>> decisions
>> >> across space, time, and frequency, so every AP treats overlap as loss
>> >> and reacts using local, partial information. Neighbor coordination
>> >> cannot recover information that was never collected, nor can it impose
>> >> deterministic service intervals on autonomous 802.11 MAC state machines
>> >> running in opaque vendor firmware.
>> >>
>> >> Fi-Wi inverts that architecture. The 802.11 MAC moves to the
>> >> concentrator, where the observations are co-located and scheduling
>> >> decisions are made in software the operator or building owner controls.
>> >> The radios handle PHY/RF execution. One RRH or twenty, the
>> architectural
>> >> property is the same: airtime scheduling, transport feedback, and
>> >> observability exist in one place.
>> >>
>> >> I put together a small animation showing how contention probability
>> >> rises rapidly even with relatively small contention windows and
>> moderate
>> >> active station counts. It helps visualize why systems often become
>> >> MAC-limited before PHY-limited:
>> >>
>> >> https://www.umbernetworks.com/csma-preview.html
>> >>
>> >> The "single network" is ultimately a human management abstraction. RF,
>> >> like rats, does not respect property boundaries. The medium is shared
>> >> whether or not the management plane pretends otherwise. Coordination
>> >> between autonomous networks tries to paper over a partition we
>> invented,
>> >> and the ceiling is set by the partition. Fi-Wi doesn't eliminate the
>> >> partition globally. It dissolves it within a coverage area, by
>> replacing
>> >> autonomous APs with radio arrays serving one MAC. Inside the domain,
>> >> there is no partition to paper over. Engineering that matches physics
>> is
>> >> the goal.
>> >>
>> >> Bob
>>
>>
>> We were having an offshoot conversation about this thread so I thought
>> I'd pop in and add my 'boots on the ground' perspective.
>>
>> FiWi sounds great technology wise, however, WiFi has gotten very good
>> and most of the benefits touted by FiWi are basically also in
>> ultra-modern wifi.
>>
>> OFDMA is now standard in WiFi7+, so the CSMA argument is fading at a
>> decent clip.
>> Device churn puts more and more OFDMA capable devices on networks all
>> the time.  We're seeing conservatively 25% of connected clients having
>> OFDMA capable radios, namely smart phones and laptops.  Some days that
>> number is much higher and there's a practical '5 year' window here on
>> old tech for these devices.  IoT devices and 'appliances' like
>> printers will lag on much longer.  Every new smartphone sold in the
>> last 1-2 years already does it, and basically any laptop sold in the
>> last year also.
>> Splitting 2.4/5/6 into 2.4 legacy/IoT 'CSMA', then 5/6 in OFDMA works
>> exceptionally well, and some enterprise APs have 2 5Ghz radios so you
>> get 2.4/5 legacy + 5/6 OFDMA on different channels.
>> Some enterprise APs can sync timing to improve re-use.
>> A number of vendors offer directional (namely downwarn cone) antennas
>> for spot coverage for scale
>> And it's all on today's physical infrastructure, 1/2.5/5Gbps ports on
>> enterprise APs and so on.
>> Nothing stopping a WiFi AP from handling AQM, ECN, etc.  CPUs *are* a
>> bottleneck on cheaper APs, but on enterprise hardware they either have
>> a fast enough CPU or they have a hardware offload for the
>> radio/ethernet bridge.  Any shortcoming here is IMO entirely based on
>> the vendor's not believing the feature is worth implementing.
>> MUMIMO on enterprise APs (with OFDMA) is fantastic and that really
>> helps reduce co-interference.
>>
>>
>> The one I guess 'unique' feature of the FiWi pitch that is unmatched
>> (or unmatchable?) is scheduling transmission on the RRH that the
>> system calculates is best for the receiver and that client device not
>> really caring which 'AP' it comes from.  ie, no Client:AP 1:1
>> association that relies on roaming for seamless coverage but is at the
>> end of the day still 1:1.  To me, this is really the only killer
>> feature, and really it's probably something WiFi can and will
>> implement in the future.  I'm including client transmissions and
>> redundancy handling in this piece too, killer feature, no reason
>> standard WiFi can't do this in a future version that would potentially
>> land before FiWi was a practical reality.
>>
>> However, my thought is that it will take far less time for all wifi
>> client devices to be upgraded/replaced with OFDMA capable units.
>> Fundamentally changing the way 'wifi/FiWi' is deployed in buildings
>> with home-run fiber is likely extremely niche.
>>
>> In the market, the ad-hoc device model, even coordinated with a
>> controller, has beaten out the centrally managed solution over and
>> over. FiWi is mainframe-to-terminal/thin_client to WiFi's
>> AP/thick_client model.  I think that analogy would likely be how the
>> market would look if FiWi were to proceed as some desire.
>>
>> I'd also argue that stand alone APs coordinated by a controller are a
>> scale-out model.  Putting cake on the wifi interfaces (which is NOT
>> common....) scales cake out to the CPU on those APs instead of leaning
>> on one central CPU.  The WiFi model also is a bit more automatically
>> redundant.  Each AP can do 'everything' and the only thing at the core
>> is a switch, and most enterprise APs have dual ports and can do some
>> method of bonding/MLAGG/etc.  VS a single core controller and RRH, a
>> failure would seem a bit more catastrophic.
>>
>> Just thoughts though.
>> _______________________________________________
>> Rpm mailing list -- rpm@lists.bufferbloat.net
>> To unsubscribe send an email to rpm-leave@lists.bufferbloat.net
>
>

I don't have arguments on the technical bits of your reply.

I do have one point of argument though.   I'm saying OFDMA, MUMIMO, etc etc
and quoting features, that's true, but I'm also deploying enterprise APs,
having hundreds of users on individual APs, and pushing multigig on those
APs while under pressure.  A few weekends back a church we service that has
6 E7 Campus APs downward firing in their event room bumped up against 4Gbps
peaks for a conference they had, mostly wifi but their media server is
wired.    We routinely push >2Gbps on a pair of E7 units at a local sports
bar where they do sports betting and people bring in ipads and the stream
horse racing etc without an issue, capacity in the room is 600 but
practically it's about 250 people but at least 1 device per if not 2.  I
have another sports bar that we stream to 26 TVs on 4 ubiquiti U7 Pro
access points, run the POS, guest wifi, and a sonos system flawlessly.

And we have a 200 room hotel we retrofitted to unifi a few months back that
doesn't have cable tv services, they have streaming services over wifi.
again, absolutely smooth sailing with just a Unifi U7 Pro arranged to cover
6 rooms each.  WAN bandwidth is the primary issue and so I have 2x '1Gx35M'
DOCSIS services in because the wifi system can saturate it.

It's extremely easy to quote features, but I'm seeing the results of those
features live.  And since ubiquiti's U7/E7 launched, we've stopped
deploying Aruba and Ruckus so I'm basically getting these results on the
lower end of the WiFi7 enterprise scale, some might reject me calling
Ubiquiti Unifi enterprise at all.

I should also mention that I have a few thousand Eero 6/7 units deployed in
the wISP operation and they get better with time as people upgrade their
phones and laptops.

I'm deep in practical deployment over a couple of US States and WiFi >=6 is
getting so good that it's no longer generating service calls.

And just to try to loop things back to the core mailing list topic, we run
Mikrotik CCR2116 units at the larger venues with a cake shaper per IP
(built using scripts) and I'm very excited to replace the one in our
largest hotel with a libreqos box from Frank's team.  The Unifi 'smart
shapers' are just not adequate, need REAL cake.

I absolutely agree that there are multiple evaluation methods.  I think
that this thread is focused mostly on the engineering side, but the other
side is the one that pays for things.  What are my deliverables?
essentially.  My arguments aren't that WiFi is superior, it's that WiFi has
evolved to the point that most of the deficits are worked around more than
adequately to meet the needs of the buyers and users.  And if you are
buying a system to support your campus network or event center and WiFi
meets all the performance needs, then the alternative must compete on
cost.  up front cost or maintenance cost.  I'm not sure FiWi is even
targeting a lower cost than WiFi.