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

[Robert McMahon <rjmcmahon@rjmcmahon.com>]

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
>