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

[David Lang <david@lang.hm>]

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