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

[Codel] "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

[Codel] 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

[Codel] 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

[Codel] 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

[Codel] 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

[Codel] 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

[Codel] 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

[Codel] 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

[Codel] 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

[Codel] Re: [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

[Codel] Re: [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

[Codel] Re: [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

[Codel] Re: [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
>

[Codel] Re: [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.

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

[Robert McMahon]

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
>

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

[dan]

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.

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

[bob.mcmahon]

> 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

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

[dan]

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] Re: [Rpm] Re: [Bloat] Re: [Cake] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon

[Frantisek Borsik]

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] Re: [Rpm] Re: [Bloat] Re: [Cake] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon

[bob.mcmahon]

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] Re: [Rpm] Re: [Bloat] Re: [Cake] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon

[Frantisek Borsik]

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.

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.
Jonathan Morton will deliver his improvement on CAKE, we might even get
into microsecond territory. 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] Re: [Rpm] Re: [Bloat] Re: [Cake] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon

[Sebastian Moeller]

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.

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

[Frantisek Borsik]

Not saying that modern Wi-Fi has no issues or that these issues will be
mitigated at all (let alone any time soon), but compensated with FQ-CoDel
and CAKE, coupled with QoE middle-box and proper peering, it's more than
just good enough. And it's here, at the our disposal. This knowledge it's
just not evenly distributed and used at scale.

I'm not claiming any special knowledge of Jonathan's work on his new
generation of queuing discipline(s), but I remember discussions with Dave
re: getting into micro-seconds territory. I still do believe that super
smart people from these lists can dig up something helpful from Dave's
scoping of CAKEMQ:
https://docs.google.com/document/d/1tTYBPeaRdCO9AGTGQCpoiuLORQzN_bG3TAkEolJPh28/edit?tab=t.0

As for 3GPP playbook, not at all. Wi-Fi is getting objectively better, so
all I'm saying is that we can reasonably expect some improvements on it
with Wi-Fi 8.
This is nothing close to 3GPP B(ritish) S(tandarts) playbook :)

Let me share a story. Back then in 2023, Dave sent me to Wi-Fi Alliance
meeting here in Prague with a list of pleas, asks and questions. There was
a few great people from the bufferbloat mailing lists and LibreQoS
customers helping to put it together. And one great person from Qualcomm
got me in, made introductions to everybody and their mother: from Broadcom,
to Intel, to MediaTek, to HPE, to Juniper, to Cisco, to his Qualcomm
colleagues. What I've learned? They are not giving a flying F about really
fixing bufferbloat. For the most part, most of them, with REAL deal, like
baking FQ-CoDel and CAKE into Wi-Fi. All they will do is some virtue
signalling at best, like introducing a "Wi-Fi QoS management
<https://www.rcrwireless.com/20251205/network-infrastructure/wi-fi-qos>"
and other things, which are marginal, potential improvements, at best.

We will have more vendors adopting FQ-CoDel and CAKE (and it's iterations)
over time, but other than that, it will be QoE middle-boxes that will
really manage to deliver these improvements at scale, in more than just ISP
networks out there. University campuses, venues, airports, manufacturing
plants, mines, cruise ships, aircraft...

So QoE middle-boxes and bufferbloat, Open Source, communities, will be
saving the day. Can Fi-Wi find some niche use case or help Wi-Fi to fix
some of its inherent issues? Absolutely.

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 Mon, May 25, 2026 at 8:59 AM Sebastian Moeller <moeller0@gmx.de> wrote:

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

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

[Sebastian Moeller]

Hi Frank,

(I shortened the CC list, I believe the list sghould suffice, no?)

> On May 25, 2026, at 14:45, Frantisek Borsik <frantisek.borsik@gmail.com> wrote:
> 
> Not saying that modern Wi-Fi has no issues or that these issues will be mitigated at all (let alone any time soon), but compensated with FQ-CoDel and CAKE, coupled with QoE middle-box and proper peering, it's more than just good enough.

I respectfully disagree, and I am not saying this to spite you, but because I am currently running some WiFi experiments in my home network, and to my taste it is not good enough. And that is with OpenWrt APs that already support:

[ TXQS ]: FQ-CoDel-enabled intermediate TXQs 
[ AIRTIME_FAIRNESS ]: airtime fairness scheduling
and, where applicable
[ AQL ]: Airtime Queue Limits (AQL)

with the following aql twaeks
# AQL Tweaks
aql_txq_limit_l=2500
aql_txq_limit_h=8500
for ac in 0 1 2 3; do echo $ac $aql_txq_limit_l $aql_txq_limit_h > /sys/kernel/debug/ieee80211/phy0/aql_txq_limit; done
for ac in 0 1 2 3; do echo $ac $aql_txq_limit_l $aql_txq_limit_h > /sys/kernel/debug/ieee80211/phy1/aql_txq_limit; done

so from the wifi side this is close to as good as it currently gets for Linux/OpenWrt with open source drivers (for WiFi4/5/6 APs)

and still under WiFi-limited scenarios h++ps://test.libreqos.com shows latency excursions into thte 500-900ms range. For my taste that certainly leaves ample room for improvements. Sure, when I get closer to the AP so WiFi throughput exceeds WAN throughput my WAN shaper kicks in and I get decent test results (with no noticeable increase in latency-under-load), but that is a work-around only.

> And it's here, at the our disposal. This knowledge it's just not evenly distributed and used at scale.

Again, knowledge is fine, but not sufficient, if I run my APs under-capacity (that is if my WAN shaper limits traffic rates to well below WiFi capacity) things look "solved" but the moment the AP is further away and the signal gets weaker things go pear shaped fast. IMHO this is not a roaming issue (sure it would be nice if stations would always pick the best AP) but really a "performance under saturating conditions" issue that ideally should be fixed, as "never let the WiFi become the bottleneck" is not a real solution and also IMHO not what "make WiFi fast" was all about.

> 
> I'm not claiming any special knowledge of Jonathan's work on his new generation of queuing discipline(s), but I remember discussions with Dave re: getting into micro-seconds territory. I still do believe that super smart people from these lists can dig up something helpful from Dave's scoping of CAKEMQ:
> https://docs.google.com/document/d/1tTYBPeaRdCO9AGTGQCpoiuLORQzN_bG3TAkEolJPh28/edit?tab=t.0
> 
> As for 3GPP playbook, not at all. Wi-Fi is getting objectively better, so all I'm saying is that we can reasonably expect some improvements on it with Wi-Fi 8. 
> This is nothing close to 3GPP B(ritish) S(tandarts) playbook :)

From my perspective you just drunk the IEEE cool-aid ;)

> 
> Let me share a story. Back then in 2023, Dave sent me to Wi-Fi Alliance meeting here in Prague with a list of pleas, asks and questions. There was a few great people from the bufferbloat mailing lists and LibreQoS customers helping to put it together. And one great person from Qualcomm got me in, made introductions to everybody and their mother: from Broadcom, to Intel, to MediaTek, to HPE, to Juniper, to Cisco, to his Qualcomm colleagues. What I've learned? They are not giving a flying F about really fixing bufferbloat. For the most part, most of them, with REAL deal, like baking FQ-CoDel and CAKE into Wi-Fi. All they will do is some virtue signalling at best, like introducing a "Wi-Fi QoS management" and other things, which are marginal, potential improvements, at best.

That seems close to the 3GPPP playbook to me, over-promise, under-deliver. That is not to say that 3GPP or IEEE do not advance their respective technologies, but not in the specific way that we are discussing here, I feel we are just a bullet point in their marketing slides, not a core engineering issue (and that is sort of OK, I just wish marketing would soften the latency claims until engineering is actually "on it").

But see above, the Linux WiFI stack already includes fq-codel and still performance under saturating conditions is less than ideal.

> 
> We will have more vendors adopting FQ-CoDel and CAKE (and it's iterations) over time, but other than that, it will be QoE middle-boxes that will really manage to deliver these improvements at scale, in more than just ISP networks out there. University campuses, venues, airports, manufacturing plants, mines, cruise ships, aircraft...

See, I am in this long enough to understand that this is really really sub-optimal for variable-rate links. Will FiWi solve all of these issues? Likely not, but it addresses (some of) them at their root, which seems the right thing to do. One of the open questions is, will FiWi actually make live better for the billions of existing WiFi devices in the field, if it does, more power to it, as IEEE's approach will likely not help there at all.

> 
> So QoE middle-boxes and bufferbloat, Open Source, communities, will be saving the day.

I like the spirit!

> Can Fi-Wi find some niche use case or help Wi-Fi to fix some of its inherent issues? Absolutely.

Not sure this and the sentence before are mutually exclusive though.

> 
> All the best,
> 
> FrankFrantisek (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 Mon, May 25, 2026 at 8:59 AM Sebastian Moeller <moeller0@gmx.de> wrote:
> 
> 
> 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.