[Bloat] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon

[Bloat] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon

[Frantisek Borsik]

Interesting food for though:

"Fi-Wi is a new forwarding plane for wireless.

IP routing maps destination prefix → next hop. Ethernet bridging maps
learned MAC → port. Fi-Wi maps 802.3 aggregates (A-MPDU) → (RRH, orthogonal
slot), where an orthogonal "slot" spans time, carrier frequencies, and
eigenspaces.

Current 802.11 needs a forwarding plane. CSMA/CA via APs is collision
avoidance — delivery is emergent, no global state, no forwarding decision.
Fi-Wi replaces that with centralized decision-making running over
distributed Remote Radio Heads, connected via PCIe-over-fiber as
cache-coherent, switched DRAM. Every RRH's queue state, channel state, and
TSF clock visible to the scheduler in a single memory domain.

Same architectural leap that IP made for L3 and Ethernet made for L2. A new
industry serviced by routers. Another new industry serviced by switches.
Fi-Wi isn't a new product, it's a third forwarding plane, and an industry
yet to be built.

Umber Networks. The first company building Fi-Wi."

https://www.linkedin.com/feed/update/urn:li:activity:7460693793390968832/

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

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

[David Lang]

This approach seems like it would work when you have one or a small number of 
fi-wi routers covering an area and the users are static

but that's bad RF engineering. having more different fixed stations really 
improves your RF performance. Combine that with devices moving around and you 
are not forwarding in the wifi layer, you need to forward based on where the 
stations are. For that, the IP address (and trditional IP routing) would seem to 
be the answer,

Even when looking at transmissions to multiple stations (I assume that's what is 
meant by aggregates), that depends on both what stations are where and what data 
there is to transmit. the groupings should not be even remotely static

Now, I may have misunderstood things, and I am alwasys aware of the concept that 
the person saying that something can't be done shouldn't interfere with the 
person doing it, but this sounds like something that would work well in a lab 
and fail miserably outside of those very controlled conditions.

David Lang


On Thu, 14 May 2026, Frantisek Borsik wrote:

> Interesting food for though:
>
> "Fi-Wi is a new forwarding plane for wireless.
>
> IP routing maps destination prefix → next hop. Ethernet bridging maps
> learned MAC → port. Fi-Wi maps 802.3 aggregates (A-MPDU) → (RRH, orthogonal
> slot), where an orthogonal "slot" spans time, carrier frequencies, and
> eigenspaces.
>
> Current 802.11 needs a forwarding plane. CSMA/CA via APs is collision
> avoidance — delivery is emergent, no global state, no forwarding decision.
> Fi-Wi replaces that with centralized decision-making running over
> distributed Remote Radio Heads, connected via PCIe-over-fiber as
> cache-coherent, switched DRAM. Every RRH's queue state, channel state, and
> TSF clock visible to the scheduler in a single memory domain.
>
> Same architectural leap that IP made for L3 and Ethernet made for L2. A new
> industry serviced by routers. Another new industry serviced by switches.
> Fi-Wi isn't a new product, it's a third forwarding plane, and an industry
> yet to be built.
>
> Umber Networks. The first company building Fi-Wi."
>
> https://www.linkedin.com/feed/update/urn:li:activity:7460693793390968832/
>
> 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
> _______________________________________________
> Cake mailing list -- cake@lists.bufferbloat.net
> To unsubscribe send an email to cake-leave@lists.bufferbloat.net

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

[Frantisek Borsik]

Thanks, David. Bob's latest slide deck can add more info on this:
https://www.umbernetworks.com/DPDK_WiFi_Stockholm_Pres.html

He is here, but I'm adding him directly.

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 Thu, May 14, 2026 at 7:09 PM David Lang <david@lang.hm> wrote:

> This approach seems like it would work when you have one or a small number
> of
> fi-wi routers covering an area and the users are static
>
> but that's bad RF engineering. having more different fixed stations really
> improves your RF performance. Combine that with devices moving around and
> you
> are not forwarding in the wifi layer, you need to forward based on where
> the
> stations are. For that, the IP address (and trditional IP routing) would
> seem to
> be the answer,
>
> Even when looking at transmissions to multiple stations (I assume that's
> what is
> meant by aggregates), that depends on both what stations are where and
> what data
> there is to transmit. the groupings should not be even remotely static
>
> Now, I may have misunderstood things, and I am alwasys aware of the
> concept that
> the person saying that something can't be done shouldn't interfere with
> the
> person doing it, but this sounds like something that would work well in a
> lab
> and fail miserably outside of those very controlled conditions.
>
> David Lang
>
>
> On Thu, 14 May 2026, Frantisek Borsik wrote:
>
> > Interesting food for though:
> >
> > "Fi-Wi is a new forwarding plane for wireless.
> >
> > IP routing maps destination prefix → next hop. Ethernet bridging maps
> > learned MAC → port. Fi-Wi maps 802.3 aggregates (A-MPDU) → (RRH,
> orthogonal
> > slot), where an orthogonal "slot" spans time, carrier frequencies, and
> > eigenspaces.
> >
> > Current 802.11 needs a forwarding plane. CSMA/CA via APs is collision
> > avoidance — delivery is emergent, no global state, no forwarding
> decision.
> > Fi-Wi replaces that with centralized decision-making running over
> > distributed Remote Radio Heads, connected via PCIe-over-fiber as
> > cache-coherent, switched DRAM. Every RRH's queue state, channel state,
> and
> > TSF clock visible to the scheduler in a single memory domain.
> >
> > Same architectural leap that IP made for L3 and Ethernet made for L2. A
> new
> > industry serviced by routers. Another new industry serviced by switches.
> > Fi-Wi isn't a new product, it's a third forwarding plane, and an industry
> > yet to be built.
> >
> > Umber Networks. The first company building Fi-Wi."
> >
> >
> https://www.linkedin.com/feed/update/urn:li:activity:7460693793390968832/
> >
> > 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
> > _______________________________________________
> > Cake mailing list -- cake@lists.bufferbloat.net
> > To unsubscribe send an email to cake-leave@lists.bufferbloat.net

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

[bob.mcmahon]

David,

Thanks for your response. I do think you've actually made the case for 
Fi-Wi and not against it,

I completely agree with you that more distributed fixed radios improve 
RF performance. That's the architecture. Fi-Wi isn't one or a few 
routers. It's many RRHs distributed across the building, all connected 
via fiber to a single scheduler with full building RF state. The more 
RRHs, the better the channel geometry.

On mobility: Fi-Wi handles intra-building mobility, a client moves, the 
scheduler sees the channel state change across all RRHs and reassigns 
the client seamlessly, with no IP address change and no L3 state machine 
involved. IP routing handles inter-building mobility. These aren't 
competing; they're different layers solving different scopes of the 
problem.

On aggregates: the groupings are entirely dynamic. The scheduler decides 
per interval, based on live queue state and live channel state, which 
clients aggregate together and on which RRH. Nothing is static.

The lab-vs-real-world concern is fair to raise. We have hardware 
deployed with 24 radio heads and will be taking measurements in real 
buildings through this year. A 48 radio head system should be available 
end of the year.

Bob

On 2026-05-14 19:26, Frantisek Borsik wrote:

> Thanks, David. Bob's latest slide deck can add more info on this: 
> https://www.umbernetworks.com/DPDK_WiFi_Stockholm_Pres.html
> 
> He is here, but I'm adding him directly.
> 
> 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 Thu, May 14, 2026 at 7:09 PM David Lang <david@lang.hm> wrote:
> 
>> This approach seems like it would work when you have one or a small 
>> number of
>> fi-wi routers covering an area and the users are static
>> 
>> but that's bad RF engineering. having more different fixed stations 
>> really
>> improves your RF performance. Combine that with devices moving around 
>> and you
>> are not forwarding in the wifi layer, you need to forward based on 
>> where the
>> stations are. For that, the IP address (and trditional IP routing) 
>> would seem to
>> be the answer,
>> 
>> Even when looking at transmissions to multiple stations (I assume 
>> that's what is
>> meant by aggregates), that depends on both what stations are where and 
>> what data
>> there is to transmit. the groupings should not be even remotely static
>> 
>> Now, I may have misunderstood things, and I am alwasys aware of the 
>> concept that
>> the person saying that something can't be done shouldn't interfere 
>> with the
>> person doing it, but this sounds like something that would work well 
>> in a lab
>> and fail miserably outside of those very controlled conditions.
>> 
>> David Lang
>> 
>> On Thu, 14 May 2026, Frantisek Borsik wrote:
>> 
>>> Interesting food for though:
>>> 
>>> "Fi-Wi is a new forwarding plane for wireless.
>>> 
>>> IP routing maps destination prefix → next hop. Ethernet bridging maps
>>> learned MAC → port. Fi-Wi maps 802.3 aggregates (A-MPDU) → (RRH, 
>>> orthogonal
>>> slot), where an orthogonal "slot" spans time, carrier frequencies, 
>>> and
>>> eigenspaces.
>>> 
>>> Current 802.11 needs a forwarding plane. CSMA/CA via APs is collision
>>> avoidance -- delivery is emergent, no global state, no forwarding 
>>> decision.
>>> Fi-Wi replaces that with centralized decision-making running over
>>> distributed Remote Radio Heads, connected via PCIe-over-fiber as
>>> cache-coherent, switched DRAM. Every RRH's queue state, channel 
>>> state, and
>>> TSF clock visible to the scheduler in a single memory domain.
>>> 
>>> Same architectural leap that IP made for L3 and Ethernet made for L2. 
>>> A new
>>> industry serviced by routers. Another new industry serviced by 
>>> switches.
>>> Fi-Wi isn't a new product, it's a third forwarding plane, and an 
>>> industry
>>> yet to be built.
>>> 
>>> Umber Networks. The first company building Fi-Wi."
>>> 
>>> https://www.linkedin.com/feed/update/urn:li:activity:7460693793390968832/
>>> 
>>> 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
>>> _______________________________________________
>>> Cake mailing list -- cake@lists.bufferbloat.net
>>> To unsubscribe send an email to cake-leave@lists.bufferbloat.net

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

[David Lang]

bob.mcmahon@umbernetworks.com wrote:

> Thanks for your response. I do think you've actually made the case for Fi-Wi 
> and not against it,

I took a quick look at the slide deck that was posted, and where there is a 
little I quibble with (CDMA hasn't really been a thing on ethernet since the 
migration to switches) there is a lot more here than the email that I replied to 
was explining

I haven't gone through all of it by any means, but it may be that the way to 
present this is more of a 'switching layer for wifi'. You talk about new 
hardware designs, but that's going to be rather expensive to do. what can be 
done with existing chips? Especially with OpenWRT (including custom firmware for 
the wifi chipsets). If it's something that can be deployed and experimented with 
under real-life conditions, that can then justify the specialized chips.

I think that lot of the wifi chip design today is offloading complexity so that 
the chips can be attached to very low-end CPUs, and that carries over into the 
AP design as well (I really don't understand why so many high-end devices put 
such puny CPUs in the center. I get that the ASICs push the load out, but when 
you are talking about devices that run thousands of dollars each, shaving tens 
of dollars to put a very low-end cpu in the core doesn't seem like the best 
idea)

again, I haven't finished going through the slide deck, so apologies if you have 
already covered this, but you also need to explain why this is better than the 
current dawn/usteer 802.11r/k solutions

David Lang

> I completely agree with you that more distributed fixed radios improve RF 
> performance. That's the architecture. Fi-Wi isn't one or a few routers. It's 
> many RRHs distributed across the building, all connected via fiber to a 
> single scheduler with full building RF state. The more RRHs, the better the 
> channel geometry.
>
> On mobility: Fi-Wi handles intra-building mobility, a client moves, the 
> scheduler sees the channel state change across all RRHs and reassigns the 
> client seamlessly, with no IP address change and no L3 state machine 
> involved. IP routing handles inter-building mobility. These aren't competing; 
> they're different layers solving different scopes of the problem.
>
> On aggregates: the groupings are entirely dynamic. The scheduler decides per 
> interval, based on live queue state and live channel state, which clients 
> aggregate together and on which RRH. Nothing is static.
>
> The lab-vs-real-world concern is fair to raise. We have hardware deployed 
> with 24 radio heads and will be taking measurements in real buildings through 
> this year. A 48 radio head system should be available end of the year.
>
> Bob
>
> On 2026-05-14 19:26, Frantisek Borsik wrote:
>
>> Thanks, David. Bob's latest slide deck can add more info on this: 
>> https://www.umbernetworks.com/DPDK_WiFi_Stockholm_Pres.html
>> 
>> He is here, but I'm adding him directly.
>> 
>> 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 Thu, May 14, 2026 at 7:09 PM David Lang <david@lang.hm> wrote:
>> 
>>> This approach seems like it would work when you have one or a small number 
>>> of
>>> fi-wi routers covering an area and the users are static
>>> 
>>> but that's bad RF engineering. having more different fixed stations really
>>> improves your RF performance. Combine that with devices moving around and 
>>> you
>>> are not forwarding in the wifi layer, you need to forward based on where 
>>> the
>>> stations are. For that, the IP address (and trditional IP routing) would 
>>> seem to
>>> be the answer,
>>> 
>>> Even when looking at transmissions to multiple stations (I assume that's 
>>> what is
>>> meant by aggregates), that depends on both what stations are where and 
>>> what data
>>> there is to transmit. the groupings should not be even remotely static
>>> 
>>> Now, I may have misunderstood things, and I am alwasys aware of the 
>>> concept that
>>> the person saying that something can't be done shouldn't interfere with 
>>> the
>>> person doing it, but this sounds like something that would work well in a 
>>> lab
>>> and fail miserably outside of those very controlled conditions.
>>> 
>>> David Lang
>>> 
>>> On Thu, 14 May 2026, Frantisek Borsik wrote:
>>> 
>>>> Interesting food for though:
>>>> 
>>>> "Fi-Wi is a new forwarding plane for wireless.
>>>> 
>>>> IP routing maps destination prefix → next hop. Ethernet bridging maps
>>>> learned MAC → port. Fi-Wi maps 802.3 aggregates (A-MPDU) → (RRH, 
>>>> orthogonal
>>>> slot), where an orthogonal "slot" spans time, carrier frequencies, and
>>>> eigenspaces.
>>>> 
>>>> Current 802.11 needs a forwarding plane. CSMA/CA via APs is collision
>>>> avoidance -- delivery is emergent, no global state, no forwarding 
>>>> decision.
>>>> Fi-Wi replaces that with centralized decision-making running over
>>>> distributed Remote Radio Heads, connected via PCIe-over-fiber as
>>>> cache-coherent, switched DRAM. Every RRH's queue state, channel state, 
>>>> and
>>>> TSF clock visible to the scheduler in a single memory domain.
>>>> 
>>>> Same architectural leap that IP made for L3 and Ethernet made for L2. A 
>>>> new
>>>> industry serviced by routers. Another new industry serviced by switches.
>>>> Fi-Wi isn't a new product, it's a third forwarding plane, and an industry
>>>> yet to be built.
>>>> 
>>>> Umber Networks. The first company building Fi-Wi."
>>>> 
>>>> https://www.linkedin.com/feed/update/urn:li:activity:7460693793390968832/
>>>> 
>>>> 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
>>>> _______________________________________________
>>>> Cake mailing list -- cake@lists.bufferbloat.net
>>>> To unsubscribe send an email to cake-leave@lists.bufferbloat.net

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

[bob.mcmahon]

David,

Thanks for taking the time to collaborate. This kind of pushback helps.

The "why now" question is worth addressing directly because it changes 
the hardware economics argument.

The PCIe lane explosion in server and workstation class CPUs, driven 
entirely by AI and HPC demand, made the memory-domain architecture 
feasible without custom silicon today. Threadripper PRO, EPYC, Sapphire 
Rapids: 128+ lanes designed to feed GPU arrays. (Technologies like DPDK 
and IOMMUs also help.) The RRH silicon is commodity 802.11 (MediaTek 
MT7922/MT7925).

In semiconductors, costs are dominated by Non-Recurring Engineering 
(NRE), the up front investment in chip design, IP blocks, and mask sets, 
not the marginal cost to manufacture each unit. A mobile Wi-Fi chip 
costs $3-8 not because it's cheap to design, but because $40-50B in NRE 
was spread across two billion units a year. Umber gets access to that 
fully amortized NRE at commodity prices. The fiber optics ride the same 
dynamic via data center volumes. PCIe retimers are a more recent 
addition to this ecosystem, developed to extend high-speed PCIe signals 
across longer distances inside AI clusters and hyperscale data centers. 
Without them, PCIe-over-fiber at building scale would not be practical. 
Umber assembles components whose development costs were paid by other 
industries. That's the near-term hardware story.

The longer-term story for our industry is different. Following O-RAN's 
split 8, the functional split between RF and all digital processing, 
puts the z-domain (digital signal processing) and MAC for a building or 
complex entirely at the concentrator. That requires a new class of RRH 
silicon optimized for centralized architectures rather than autonomous 
AP operation. There is significant industry interest in winning that 
socket.

When fiber-to-the-room (FTTR) scales worldwide, the unit volumes for RRH 
silicon will exceed mobile. Every room in every building is a space to 
serve, with likely multiple RRHs per room. This is analogous to LED 
bulbs used for illumination. These worldwide volumes justify new NRE, 
and several silicon companies are watching this space closely. Those 
that engage early have a higher probability of becoming the primary 
supplier.

On your stepping-stone question: OpenWRT and dawn get us partway. The 
ceiling is the MAC still running autonomously inside each AP, making 
local decisions without global RF state. A shared memory-domain 
architecture makes globally scheduled transmission practical in ways 
autonomous AP architectures cannot. You can steer clients with dawn; you 
cannot schedule transmissions across RRHs. That distinction is the 
difference between optimizing a CSMA/CA system and replacing it.

On dawn/usteer and 802.11r/k: these are steering protocols layered on 
top of CSMA/CA. They help clients find a better AP but each AP still 
contends independently for the medium. No global scheduler, no 
coordinated transmission, no spatial stream coordination across RRHs. 
These systems improve client placement within a distributed contention 
architecture. Fi-Wi instead centralizes airtime scheduling itself.

On what improves first and is measurable: roaming latency drops to near 
zero because association never changes. Hidden node problems disappear 
because there is no contention. MU-MIMO utilization becomes a scheduling 
decision rather than a statistical outcome. Deterministic latency, which 
802.11 cannot guarantee by design, becomes a first-class deliverable. 
Those are the metrics we will be publishing from real building 
deployments through this year.

Bob

On 2026-05-14 21:55, David Lang wrote:
> bob.mcmahon@umbernetworks.com wrote:
> 
>> Thanks for your response. I do think you've actually made the case for 
>> Fi-Wi and not against it,
> 
> I took a quick look at the slide deck that was posted, and where there 
> is a little I quibble with (CDMA hasn't really been a thing on ethernet 
> since the migration to switches) there is a lot more here than the 
> email that I replied to was explining
> 
> I haven't gone through all of it by any means, but it may be that the 
> way to present this is more of a 'switching layer for wifi'. You talk 
> about new hardware designs, but that's going to be rather expensive to 
> do. what can be done with existing chips? Especially with OpenWRT 
> (including custom firmware for the wifi chipsets). If it's something 
> that can be deployed and experimented with under real-life conditions, 
> that can then justify the specialized chips.
> 
> I think that lot of the wifi chip design today is offloading complexity 
> so that the chips can be attached to very low-end CPUs, and that 
> carries over into the AP design as well (I really don't understand why 
> so many high-end devices put such puny CPUs in the center. I get that 
> the ASICs push the load out, but when you are talking about devices 
> that run thousands of dollars each, shaving tens of dollars to put a 
> very low-end cpu in the core doesn't seem like the best idea)
> 
> again, I haven't finished going through the slide deck, so apologies if 
> you have already covered this, but you also need to explain why this is 
> better than the current dawn/usteer 802.11r/k solutions
> 
> David Lang
> 
>> I completely agree with you that more distributed fixed radios improve 
>> RF performance. That's the architecture. Fi-Wi isn't one or a few 
>> routers. It's many RRHs distributed across the building, all connected 
>> via fiber to a single scheduler with full building RF state. The more 
>> RRHs, the better the channel geometry.
>> 
>> On mobility: Fi-Wi handles intra-building mobility, a client moves, 
>> the scheduler sees the channel state change across all RRHs and 
>> reassigns the client seamlessly, with no IP address change and no L3 
>> state machine involved. IP routing handles inter-building mobility. 
>> These aren't competing; they're different layers solving different 
>> scopes of the problem.
>> 
>> On aggregates: the groupings are entirely dynamic. The scheduler 
>> decides per interval, based on live queue state and live channel 
>> state, which clients aggregate together and on which RRH. Nothing is 
>> static.
>> 
>> The lab-vs-real-world concern is fair to raise. We have hardware 
>> deployed with 24 radio heads and will be taking measurements in real 
>> buildings through this year. A 48 radio head system should be 
>> available end of the year.
>> 
>> Bob
>> 
>> On 2026-05-14 19:26, Frantisek Borsik wrote:
>> 
>>> Thanks, David. Bob's latest slide deck can add more info on this: 
>>> https://www.umbernetworks.com/DPDK_WiFi_Stockholm_Pres.html
>>> 
>>> He is here, but I'm adding him directly.
>>> 
>>> 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 Thu, May 14, 2026 at 7:09 PM David Lang <david@lang.hm> wrote:
>>> 
>>>> This approach seems like it would work when you have one or a small 
>>>> number of
>>>> fi-wi routers covering an area and the users are static
>>>> 
>>>> but that's bad RF engineering. having more different fixed stations 
>>>> really
>>>> improves your RF performance. Combine that with devices moving 
>>>> around and you
>>>> are not forwarding in the wifi layer, you need to forward based on 
>>>> where the
>>>> stations are. For that, the IP address (and trditional IP routing) 
>>>> would seem to
>>>> be the answer,
>>>> 
>>>> Even when looking at transmissions to multiple stations (I assume 
>>>> that's what is
>>>> meant by aggregates), that depends on both what stations are where 
>>>> and what data
>>>> there is to transmit. the groupings should not be even remotely 
>>>> static
>>>> 
>>>> Now, I may have misunderstood things, and I am alwasys aware of the 
>>>> concept that
>>>> the person saying that something can't be done shouldn't interfere 
>>>> with the
>>>> person doing it, but this sounds like something that would work well 
>>>> in a lab
>>>> and fail miserably outside of those very controlled conditions.
>>>> 
>>>> David Lang
>>>> 
>>>> On Thu, 14 May 2026, Frantisek Borsik wrote:
>>>> 
>>>>> Interesting food for though:
>>>>> 
>>>>> "Fi-Wi is a new forwarding plane for wireless.
>>>>> 
>>>>> IP routing maps destination prefix → next hop. Ethernet bridging 
>>>>> maps
>>>>> learned MAC → port. Fi-Wi maps 802.3 aggregates (A-MPDU) → (RRH, 
>>>>> orthogonal
>>>>> slot), where an orthogonal "slot" spans time, carrier frequencies, 
>>>>> and
>>>>> eigenspaces.
>>>>> 
>>>>> Current 802.11 needs a forwarding plane. CSMA/CA via APs is 
>>>>> collision
>>>>> avoidance -- delivery is emergent, no global state, no forwarding 
>>>>> decision.
>>>>> Fi-Wi replaces that with centralized decision-making running over
>>>>> distributed Remote Radio Heads, connected via PCIe-over-fiber as
>>>>> cache-coherent, switched DRAM. Every RRH's queue state, channel 
>>>>> state, and
>>>>> TSF clock visible to the scheduler in a single memory domain.
>>>>> 
>>>>> Same architectural leap that IP made for L3 and Ethernet made for 
>>>>> L2. A new
>>>>> industry serviced by routers. Another new industry serviced by 
>>>>> switches.
>>>>> Fi-Wi isn't a new product, it's a third forwarding plane, and an 
>>>>> industry
>>>>> yet to be built.
>>>>> 
>>>>> Umber Networks. The first company building Fi-Wi."
>>>>> 
>>>>> https://www.linkedin.com/feed/update/urn:li:activity:7460693793390968832/
>>>>> 
>>>>> 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
>>>>> _______________________________________________
>>>>> Cake mailing list -- cake@lists.bufferbloat.net
>>>>> To unsubscribe send an email to cake-leave@lists.bufferbloat.net

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

[David Lang]

bob.mcmahon@umbernetworks.com wrote:

> On dawn/usteer and 802.11r/k: these are steering protocols layered on top of 
> CSMA/CA. They help clients find a better AP but each AP still contends 
> independently for the medium. No global scheduler, no coordinated 
> transmission, no spatial stream coordination across RRHs. These systems 
> improve client placement within a distributed contention architecture. Fi-Wi 
> instead centralizes airtime scheduling itself.
>
> On what improves first and is measurable: roaming latency drops to near zero 
> because association never changes. Hidden node problems disappear because 
> there is no contention. MU-MIMO utilization becomes a scheduling decision 
> rather than a statistical outcome. Deterministic latency, which 802.11 cannot 
> guarantee by design, becomes a first-class deliverable. Those are the metrics 
> we will be publishing from real building deployments through this year.

I get the difference now, scheduling all RF transmissions across all devices 
from ne central system, that's ambitious and seems like it would hae scaling 
problems (even just the metadata is a lot of informatin to run through a single 
system with very tight timing requirements)

You speak of fiber to the room, but that doesn't seem to be the trend that I 
see. I see less interest in connections to rooms (fiber or copper), with 
'everyone will just use wifi', and reluctance to wire for the APs. I would love 
it if you had the fantastic capabilities to all the appropriate AP locations (it 
doesn't help that the 'enterprise' vendors tell them to just put in a small 
number of their multi-radio/multi-antenna/zoned APs to cover everything)

at best, you can end up controlling the AP transmissions of your APs. you can't 
control the client transmission scheduling, and you can't control other systems 
(upstairs/downstairs/adjacent neighbors, personal hotspots, etc)

the RF environment also changes depending on doors open, temporary furniture, 
room occupation, etc. You will not only need a lot of control of the 
transmitters, but you will also need a lot of receiving stations listening to 
the spectrum to hear what else is out there. This is possible with software 
defined radio receiviers, but not easy due to the very wide bandwidth that needs 
to be monitored.

On top of this, you aren't talking about one plane of RF, you have lots of them, 
one per channel, just minimizing co-channel interference by allocating the 
channels properly does wonders for performance, but is a rather hard real-world 
problem in the changing rf environment. Depending on if you can use DFS channels 
and what channel width you provide, (are you optimizing for a small number of 
high bandwidht clients, or a large number of lower bandwidth clients) the number 
of RF planes to optimize can vary. I find that lots of narrow channels re-used 
at close distances works well for conference type settings (even without 
802.11k/r). My biggest problem is clients that don't want to cooperate (apple 
being a big one)

interesting, but still a bit skeptical that this is a problem that can be 
knowable enough to try to implement a global scheduler for.

David Lang

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

[David Lang]

I do like the idea of moving the scheduling smarts off of the dedicated chips 
and onto the CPU in many ways (the provided firmware is rather poor in may 
cases, plus closed source with all of the problems that entails). But it's 
hard to do even locally, let alone at scale.

I've been around long enough to remember winmodems and the difference between 
real RAID cards and the fakeraid shipped on many motherboards today. SDR radio 
receivers are fantastic, within their capability (which expands every year).

So parts of your system make a lot of sense, but other parts seem to require 
perfect knowledge of the environment, and that has never been able to work even 
on wired networks, and RF is much uglier

David Lang

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

[bob.mcmahon]

  > interesting, but still a bit skeptical that this is a problem that 
can be knowable enough to try to implement a global scheduler for.
> 

David,

The winmodem analogy is apt. Thanks for bringing it up. The pattern is 
consistent: move complexity from dedicated silicon to CPU. We win when 
the CPU gets fast enough. DPDK on a Threadripper PRO with 128 PCIe lanes 
is that moment for wireless scheduling.

On perfect knowledge: IP routing operates on incomplete topology 
information and converges. TCP congestion control has no direct 
visibility into queue state along the path and delivers traffic. BGP 
makes forwarding decisions on stale information and the internet 
functions. In each case the system improves as information quality 
increases, which is exactly what L4S marking does for congestion 
control. The question has never been whether the knowledge is perfect. 
It is whether the system is robust to imperfect information and whether 
it outperforms even with that imperfection. Fi-Wi's fallback is always 
CSMA/CA. Any improvement over that baseline under real conditions is a 
measurable win.

The Fi-Wi architecture provides materially more global state than 
independently operating APs have today. The scheduler does not need a 
perfectly knowable RF environment, just a materially better one.
The fiber run is to the RRH. The end device still uses Wi-Fi. 25B 
devices stay as they are.
Uncooperative clients fall back to CSMA/CA. The downlink scheduling 
advantage and coordinated transmitter picture still apply. And because 
collision probability increases superlinearly with contention density in 
CSMA/CA systems, even partial scheduling reduces contention pressure for 
the remaining CSMA/CA traffic disproportionately. Coordinated 
infrastructure reduces load on the shared medium even for unmanaged 
clients.

For the 25B existing devices, the infrastructure controls more than most 
deployments use today:

o) CTS-to-self creates protected transmission windows across managed 
RRHs
o) Adaptive EDCA and TXOP policies bias contention behavior dynamically
o) TCP ACK scheduling at the concentrator shapes STA transmission 
behavior through the transport layer without requiring 802.11-layer 
changes
o) Transport signals are bidirectional. L4S ECN marking and TCP Prague 
congestion responses create a control loop between the concentrator and 
STAs that influences client behavior from above the wireless layer. An 
L4S-aware STA running TCP Prague is participating in the scheduling loop 
whether or not it knows anything about Fi-Wi.
o) L4S visibility into the Wi-Fi link is critical when wireless is the 
bottleneck, which in a building deployment it almost always is. ECN 
marking at the concentrator makes that bottleneck visible to the 
transport layer for the first time, allowing TCP Prague to respond 
precisely rather than reactively. Today that information is lost inside 
opaque firmware scheduling and media access decisions.
o) UL-OFDMA trigger frames direct uplink transmission timing for the 
growing 802.11ax installed base

On RF variability: every RRH not carrying a transmission is either a 
receiver feeding aggregate channel state back to the concentrator, or 
can contribute spatial suppression via beamforming where supported. 
Building RF conditions are also learnable over time. CSI across all RRHs 
captures how the environment changes with occupancy, time of day, and 
physical configuration. The concentrator builds a temporal model of the 
building that improves scheduler decisions continuously. An autonomous 
AP has no such memory.

On channel management: dense narrow channel reuse works well. 
Experienced operators are already doing this manually. The goal is to 
make those decisions dynamic and scheduler-driven rather than static 
planning assumptions.

One underappreciated fact: 802.11 EDCA values were never meant to be 
constants. They were placeholder examples, with the expectation that a 
BSS manager would adapt them to real conditions. That BSS manager was 
never built because there was no centralized view of the RF environment 
to build it from. The placeholders became the standard. Fi-Wi directly 
addresses this. The EDCA policies become scheduler-driven rather than 
static firmware constants. The RRHs become nodes. The scheduler defines 
the edges, which radios serve which clients, on which channels, at which 
MCS, in which time slots. 802.11 hardware vendors have been making those 
decisions independently, each without any knowledge of the others, 
because there was no fronthaul architecture to make a shared view 
practical.

The real question is not whether we can fully model RF. It is whether 
centralized partial-state coordination produces measurably better 
latency distributions, airtime utilization, and roaming continuity than 
distributed partial-state contention under real RF conditions and 
bounded observability. That is a testable hypothesis. That is what we 
are validating in real building deployments through this year, focusing 
on latency distribution under load, MU-MIMO utilization, and roaming 
continuity.

This is a lot of work. A property of new industry.

Bob

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

[Livingood, Jason]

> You speak of fiber to the room, but that doesn't seem to be the trend that I
see. I see less interest in connections to rooms (fiber or copper), with
'everyone will just use wifi', and reluctance to wire for the APs.

In what country? The US? I think other countries are likely ahead of the US in wiring. In any case, I agree everyone wants to just use wireless but the in-home wireless environment is quite bad and is a key performance limiter for very nearly every home in the US. ISTM that Bob is exploring one way of trying to improve that. I do not believe it should be acceptable to us as technologists that the home network is such an intractable performance problem. ;-)

JL

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

[David Lang]

On Tue, 19 May 2026, Livingood, Jason wrote:

>> You speak of fiber to the room, but that doesn't seem to be the trend that I
>> see. I see less interest in connections to rooms (fiber or copper), with
>> 'everyone will just use wifi', and reluctance to wire for the APs.
>
> In what country? The US? I think other countries are likely ahead of the US in 
> wiring. In any case, I agree everyone wants to just use wireless but the 
> in-home wireless environment is quite bad and is a key performance limiter for 
> very nearly every home in the US. ISTM that Bob is exploring one way of trying 
> to improve that. I do not believe it should be acceptable to us as 
> technologists that the home network is such an intractable performance 
> problem. ;-)

many other countries have older houses than the US, I'd be amazed if they had 
newer wiring. (I could be wrong)

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 Lang

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

[bob.mcmahon]

> 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

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

[Frantisek Borsik]

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
>

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

[dan]

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.