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

[bob.mcmahon@umbernetworks.com]

  > 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