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

[Frantisek Borsik <frantisek.borsik@gmail.com>]

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