[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]

Dan,

Thanks for this. OFDMA in Wi-Fi 6 and 7 is a real improvement, but I 
think you are giving it more architectural weight than it has.

OFDMA is not a cost function. It is a way to divide channel bandwidth 
into resource units. Trigger frames are not a building-wide scheduler, 
or even the AP scheduler itself. They are MAC control frames used to 
tell clients what the AP's local scheduler has already decided.

The actual scheduler is still embedded in AP chipset firmware running 
autonomously. It is local to that AP, works from that AP's queue and PHY 
view, and still operates over the same contested RF medium. For uplink 
OFDMA, the trigger frame is transmitted in-band. The AP still has to win 
access to the channel via CSM/CA before it can send it.

That is not the same as a scheduler with shared state across the 
building. It does not provide common queue state across APs, 
bounded-latency PHY state from neighboring radios, or a shared airtime 
cost function that can price airtime, collision risk, retry probability, 
and tail-latency impact across the interference domain.

Your hybrid legacy design illustrates the point. Separate SSIDs, APs, 
and channels partition the problem by adding managed airtime. Useful 
engineering, yes. But partitioning only works while there is unused 
spectrum left to partition. We should not count on another large 
unlicensed band arriving that will change the economics of this problem, 
so the partitioning approach has largely run its course.

And the installed base is not turning over to Wi-Fi 7 WPA3-only behavior 
anytime soon. ESP32-class devices keep shipping because the market 
values cheap, abundant radios. These don't support trigger frames.

So I agree modern Wi-Fi is better. I do not agree the problem is 
obsolete. OFDMA improves AP-local resource allocation. It does not make 
airtime cost observable and actionable across a building.

Bob

> I have to argue these points on wifi saturation.  It's like an argument 
> from 2015, it's true for devices speaking in 2015's language but it's 
> simply false for modern APs and devices.
> 
> First, I'll acknowledge that CSMA based wifi does suck in the ways 
> described and there's no way to fix that but to replace it.  Also, any 
> AP that routinely handles CSMA clients even in mixed modes will 
> struggle with CSMA mostly from hidden node.
> 
> Also, I don't operate in a niche space, my space is where every 
> non-ethernet connected device operates.  I do home, small business, 
> large event centers, hotels, campgrounds, whole building solutions with 
> hundreds of concurrent users.  My wISP operation is the smallest part 
> of the business, it just happens to have the cheapest clients so needs 
> the cheapest solutions.  I'm the anti-niche.
> 
> The issues described above are non-OFDMA experiences.  OFDMA, at it's 
> very core, is a bi-directional scheduler that is TDMA which erases the 
> CSMA problems that cause retransmit 'storms'.  A single OFDMA AP and 
> virtually any number of OFDMA clients before you run out of CPU, will 
> not collapse under saturation on OFDMA because they have strict 
> timeslots.
> 
> Worth noting, most decent WiFi7 access points with 6Ghz can strongly 
> encourage OFDMA in clients if you setup a 6Ghz WPA3 only SSID.  It's 
> not a hard rule, but that combination generally strips out all 
> non-OFDMA speaking devices.
> 
> This comes down to quality drivers/software on the AP.  WiFi8 is still 
> a paper tiger practically speaking, but WiFi7 is out in full deployment 
> and showing it's power.  Noise at a client is reported to the AP, the 
> AP won't schedule noisy RUs to that client, and vice versa.  Multiple 
> AP deployments see the other APs and channels and schedule RUs based on 
> the amount of data to deliver.  It'll use noisy RUs at lower 
> modulations and clean ones at higher modulations and it does it 
> bi-directionally so noise at the AP can be used to transmit to clients 
> that don't see that noise and vice versa.
> 
> We have been deploying a hybrid approach with APs operating with WPA3 
> and >=80Mhz channels to encourage OFDMA and then separate APs on 
> separate channels for older devices on WPA2.
> 
> So when you guys give these anecdotal answers describing <=wifi5/CSMA, 
> I'd really like to know where and if I can get in contact with the 
> facility management and offer them a real, modern wifi network, because 
> we put a LOT of pressure on wifi and your issues are a thing of the 
> past.  They just do not happen on a well designed wifi system 
> encouraging OFDMA use and accommodating older devices.
> 
> This might be the space FiWi wants to be, but FiWi will show up to 
> solve a problem that is years in the past.
> 
> Further, I don't think Dave really cared where the bottleneck was, only 
> that there were full buffers and that was a solvable problem.  Putting 
> fq_codel or cake on the AP's interface was the ideal place to handle 
> lots of things, including device-to-device communications, but note 
> that he's a founding member of libreqos that puts the shapers on the 
> internet edge as well, and we had multiple conversations about fq_codel 
> on every intermediate port you could find, each one improving the 
> links.