From: David Lang <david@lang.hm>
To: bob.mcmahon@umbernetworks.com
Cc: David Lang <david@lang.hm>,
Frantisek Borsik <frantisek.borsik@gmail.com>,
Cake List <cake@lists.bufferbloat.net>,
Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>,
bloat <bloat@lists.bufferbloat.net>,
Jeremy Austin via Rpm <rpm@lists.bufferbloat.net>,
codel@lists.bufferbloat.net,
"Dave.seddon Ca" <dave.seddon.ca@gmail.com>,
William Fisher <zzyzxr99@gmail.com>,
Igor Aleinikov <igor.aleinikov@adnacom.com>,
Jim <jim@iniholdings.com>, Jiml <jiml@quicksmart.com>,
Douglas Fairbairn <dfairbairn@megachips.com>,
Thomas <thomas@monjalon.net>,
Tim Odriscoll <tim.odriscoll@intel.com>,
Morten <morten@broerup.com>,
Sebastian Moeller <sebastian.moeller@gmail.com>,
Mt Denicolo <mt.denicolo@gmail.com>,
Mmcmahon01 <mmcmahon01@gmail.com>,
Santanu Sinha <santanusinha@yahoo.com>,
Matthew <matthew@mteley.com>
Subject: [Cake] Re: "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon
Date: Fri, 15 May 2026 06:57:52 -0700 (MST) [thread overview]
Message-ID: <on96r301-9606-52r1-s355-24426s4sr8p9@ynat.uz> (raw)
In-Reply-To: <c474192062723232d4841e67aae8d285@umbernetworks.com>
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
next prev parent reply other threads:[~2026-05-15 13:57 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-14 16:46 [Cake] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon Frantisek Borsik
2026-05-14 17:08 ` [Cake] " David Lang
2026-05-14 17:26 ` 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 [this message]
2026-05-15 14:18 ` David Lang
2026-05-15 15:17 ` bob.mcmahon
2026-05-19 13:52 ` [Cake] 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
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/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=on96r301-9606-52r1-s355-24426s4sr8p9@ynat.uz \
--to=david@lang.hm \
--cc=bloat@lists.bufferbloat.net \
--cc=bob.mcmahon@umbernetworks.com \
--cc=cake@lists.bufferbloat.net \
--cc=codel@lists.bufferbloat.net \
--cc=dave.seddon.ca@gmail.com \
--cc=dfairbairn@megachips.com \
--cc=frantisek.borsik@gmail.com \
--cc=igor.aleinikov@adnacom.com \
--cc=jim@iniholdings.com \
--cc=jiml@quicksmart.com \
--cc=make-wifi-fast@lists.bufferbloat.net \
--cc=matthew@mteley.com \
--cc=mmcmahon01@gmail.com \
--cc=morten@broerup.com \
--cc=mt.denicolo@gmail.com \
--cc=rpm@lists.bufferbloat.net \
--cc=santanusinha@yahoo.com \
--cc=sebastian.moeller@gmail.com \
--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