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

[bob.mcmahon@umbernetworks.com]

Hi Dan,

802.11 will not define a building-wide control plane, a building-wide 
BSS manager, or a shared cost function. That architecture is outside the 
scope of the 802.11 standards and contrary to the AP vendors' business 
models.

Replacing the client base is a non-starter. Tenants, guests, IoT 
vendors, phones, cameras, laptops, and embedded devices arrive on their 
own schedules. The building has to work with the devices that show up, 
not the devices standards bodies, vendors and service providers wish 
would show up.

User experience is fundamentally defined by tail latency. The standards 
bodies and AP vendors have optimized Wi-Fi for capacity, not 
service-time control. A-MPDU is the most obvious example: larger 
aggregates improve throughput by amortizing contention and PHY overhead, 
but they also concentrate airtime into longer bursts. During that burst, 
the AP is committed to one transmission or reception and cannot serve 
other clients; every device trying to transmit through that AP to the 
WAN link has to wait. The same burst also creates interference energy 
for other BSSs that can hear it, lowering SINR while the transmission is 
active. The current system treats a larger aggregate as a capacity win 
even when it creates the tail-latency loss that drives customer 
complaints to the internet service provider.

The MCS index table makes the same point from the PHY side. A packet's 
airtime cost depends on MCS, channel width, spatial streams, guard 
interval, retries, and receiver conditions. But 802.11 leaves EDCA, 
MCS/rate control, scheduling policy, aggregation policy, and airtime 
tradeoffs inside autonomous, vendor-specific AP firmware. Operators 
cannot know, verify, or control those decisions.

What is missing are a few things. First, the interference graph: what 
one transmission costs the rest of the managed domain in other radios, 
other clients, other flows, retry probability, service-time variance, 
SINR impact, and tail-latency impact. Second, a building-wide BSS 
manager with authority to act across APs, BSS membership, channel and 
power policy, scheduling policy, aggregation policy, and airtime-cost 
enforcement. Third, ECN marking tied to scheduler-determined AMPDU 
aggregation on the WLAN side, coupled to WAN congestion and pacing 
signals.

If control decisions remain inside autonomous, vendor-specific AP 
firmware, the system cannot have a building-wide wireless forwarding 
plane. Waiting for 802.11 to define that architecture is Waiting for 
Godot. Solving it requires moving radio-resource control behind the 
fronthaul into a central concentrator.

Bob

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