From: dan <dandenson@gmail.com>
To: bob.mcmahon@umbernetworks.com
Cc: David Lang <david@lang.hm>, Sebastian Moeller <moeller0@gmx.de>,
Frantisek Borsik <frantisek.borsik@gmail.com>,
codel@lists.bufferbloat.net,
Cake List <cake@lists.bufferbloat.net>,
Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>,
bloat <bloat@lists.bufferbloat.net>, Jiml <jiml@quicksmart.com>,
William Fisher <zzyzxr99@gmail.com>, Thomas <thomas@monjalon.net>,
Tim Odriscoll <tim.odriscoll@intel.com>
Subject: [Make-wifi-fast] Re: [Bloat] Re: [Codel] [Rpm] Re: Re: [Cake] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon
Date: Sun, 7 Jun 2026 18:29:43 -0600 [thread overview]
Message-ID: <CAA_JP8UHb5WvZtAgsfQ5vxkaSxNrTmm20RPw41YwwxkHho1npA@mail.gmail.com> (raw)
In-Reply-To: <7421a405a482f9a38f100f31979b2a7c@umbernetworks.com>
WiFi and FiWi are following identical RF standards, there is no argument
between the two on this. ie the OFDMA arguments.
OFDMA does wait PER RU for CS, but only per RU, it can transmit on clean
RUs per AP. This is practically identical to FiWi's featureset because
it's also using OFDMA with CS protection on WiFi7 FiWi. There is no
advantage to FiWi here, we're all talking OFDMA to OFDMA clients.
I'll acknowledge 2.5 REAL FiWi advantages. Sorted by value in my eyes
1) combining a single client transmission received on multiple RRH
additively. Sort of 'beamforming advantage'. WiFi will likely never gain
such a feature. WiFi 9+ should get virtual AP which will look a lot like
this, but FiWi would likely always retain an edge here and it's available
*today*, likely...5-10 years out for wifi9 and this feature.
2) single presented MAC. Clients don't have to 'roam' within RRH groups.
WiFi has r/k/v roaming which is fantastic, but it is a mechanism that
requires client support. Newer WiFi devices all have this so it's a
disadvantage that fades a bit over time, but FiWi would always retain an
edge here.
3) central scheduling. FiWi with a central controller acts as one giant
MuMIMO AP *today*. WiFi was supposed to get this in 7, but it got pushed
to 8. WiFi8 does have central management and scheduling available and that
is in draft hardware today. This is the '0.5' of the 2.5 advantages.
HOWEVER, my original point is that WiFi7 today fill the vast majority of
the FiWi performance claims when the network is built and planned well.
Practical deployments, not quoting paper specs. Again, we're doing event
centers, hotels, etc and WiFi7 is like magic today, cheaply.
I'll give a specific example here that presents a challenge that FiWi
cannot practicaly service (the fiber to the RRH being the eliminator
here). We run a network is a small resort town with seamless WiFi along
the entire 1/2 mile downtown area including parts and storefronts, the zoo,
etc. We run my favorite SIP phone, the Yealink AX86R and you can walk 3
major paths and probably 20 solid minutes on foot roaming via r/k/v, with
prioritized packets, riding a network with many wifi cameras and often many
hundreds of users, and seamlessly roam through a dozen restaurants and a
couple hotels, without a hiccup. This traverses a VLAN over multiple
mmWave wireless links building a ~4Gbps mesh fabric. Modern WiFi phones
pull >1G speed tests, there are no congestion issues even during peak
season. These APs have a public SSID. WiFi7 KILLS. Same story as above,
WPA3/80Mhz channels in 5Ghz, 160Mhz in 6Ghz, makes for an almost entirely
OFDMA capable device makeup. Separate APs on WPA 2.4/5Ghz in buildings to
facilitate legacy. This is a 'very hard' wifi thing in the old days and
today, it's actually quite easy. And mind you, these are outdoor APs,
they're fighting consumer wifi noise much much more than typical. They
have to schedule around self-noise. Also note, this net runs cellular
offload so we have a LOT of 'drive-by' joins and use.
OFDMA actually *is* a magic bullet for WiFi, but the anecdotal evidence
given is *1* OFDMA bullet in a six shooter and the other 5 are 802.11n.
You cannot make strong judgements on modern wifi if you're not building
modern wifi networks.
The original premise IMO stands, modern WiFi, especially in deployments
that are FiWi targets, is already very very very good in real world
deployments.
next prev parent reply other threads:[~2026-06-08 0:29 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-14 14:40 [Make-wifi-fast] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon Frantisek Borsik
2026-05-14 17:08 ` [Make-wifi-fast] Re: [Cake] " David Lang
2026-05-14 15:20 ` Frantisek Borsik
2026-05-14 19:38 ` bob.mcmahon
2026-05-14 19:55 ` David Lang
2026-05-15 11:11 ` bob.mcmahon
2026-05-15 13:57 ` David Lang
2026-05-15 14:18 ` David Lang
2026-05-15 15:17 ` bob.mcmahon
2026-05-19 13:52 ` [Make-wifi-fast] Re: [Bloat] " Livingood, Jason
2026-05-19 18:59 ` David Lang
2026-05-19 22:45 ` bob.mcmahon
2026-05-21 19:42 ` Frantisek Borsik
2026-05-21 20:02 ` dan
2026-05-22 16:36 ` [Make-wifi-fast] Re: [Rpm] " Robert McMahon
2026-05-23 2:18 ` dan
2026-05-23 16:36 ` bob.mcmahon
2026-05-23 22:12 ` dan
2026-05-24 20:06 ` Frantisek Borsik
2026-05-24 21:57 ` bob.mcmahon
2026-05-25 5:43 ` Frantisek Borsik
2026-05-25 6:58 ` [Make-wifi-fast] Re: [Codel] " Sebastian Moeller
2026-05-25 12:45 ` Frantisek Borsik
2026-05-25 13:36 ` [Make-wifi-fast] Re: [Codel] " Sebastian Moeller
2026-06-07 6:15 ` Frantisek Borsik
2026-06-07 9:03 ` Sebastian Moeller
2026-06-07 10:19 ` [Make-wifi-fast] Re: [Bloat] Re: [Codel] [Rpm] " David Lang
2026-06-07 18:10 ` bob.mcmahon
2026-06-07 18:30 ` dan
2026-06-07 19:10 ` bob.mcmahon
2026-06-08 0:29 ` dan [this message]
2026-06-08 2:55 ` bob.mcmahon
2026-06-08 4:06 ` David Lang
2026-06-08 6:26 ` [Make-wifi-fast] Re: [Bloat] " Sebastian Moeller
2026-06-08 3:59 ` [Make-wifi-fast] Re: [Bloat] " David Lang
2026-06-08 5:18 ` bob.mcmahon
2026-06-08 6:53 ` David Lang
2026-06-08 10:29 ` Frantisek Borsik
[not found] ` <e68abec2-6fd8-4fc4-ad26-5ca10859551c@rogers.com>
2026-06-09 3:40 ` [Make-wifi-fast] Re: [Codel] Re: [Bloat] " bob.mcmahon
2026-06-07 6:49 ` [Make-wifi-fast] Re: [Bloat] Re: [Codel] " David Lang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/make-wifi-fast.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA_JP8UHb5WvZtAgsfQ5vxkaSxNrTmm20RPw41YwwxkHho1npA@mail.gmail.com \
--to=dandenson@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=bob.mcmahon@umbernetworks.com \
--cc=cake@lists.bufferbloat.net \
--cc=codel@lists.bufferbloat.net \
--cc=david@lang.hm \
--cc=frantisek.borsik@gmail.com \
--cc=jiml@quicksmart.com \
--cc=make-wifi-fast@lists.bufferbloat.net \
--cc=moeller0@gmx.de \
--cc=thomas@monjalon.net \
--cc=tim.odriscoll@intel.com \
--cc=zzyzxr99@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox