[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 David,

Thanks for the collaboration. Fixing Wi-Fi for the existing 25B and 
growing number of devices is a major challenge for our industry. Your 
thoughtful and very well-written responses help a lot.

The cliff behavior under saturation is real, and retry/rate fallback can 
make it worse. Lower MCS consumes more airtime, which increases 
collision exposure, which drives more retries and more fallback. All 
degrading tail latencies and, hence, user experience.

I think the deeper problem is that conventional Wi-Fi has no shared 
airtime cost function. Each AP and client makes local decisions from 
partial information: CCA, retries, RSSI, rate control, EDCA backoff, and 
local queue state. But no one has enough shared state to ask what a 
transmission actually costs right now in airtime, collision risk, retry 
probability, and delay imposed on other flows.

That is why more APs at lower power helps but does not fundamentally 
solve the problem. It adds spatial reuse and pushes the cliff farther 
out, but each node is still guessing about a medium it can only 
partially observe. And the number of devices keeps growing and growing.

The distinction I would draw is between scheduling over the contested RF 
medium and scheduling with an out-of-band coordination path. In-band 
scheduling burns the same airtime it is trying to preserve. Out-of-band 
scheduling changes that cost model, but only if the fronthaul satisfies 
some hard requirements: bounded worst-case latency so grants arrive 
before slots open, no contention on the control path, and enough 
bandwidth to carry both queue state and PHY state (RSSI, ED, MCS, 
spatial stream availability) back to the scheduler continuously. Without 
PHY state the scheduler knows who has data waiting but not what each 
transmission will cost in airtime or impose on tail latencies.

So I agree that current Wi-Fi under saturating load is structurally bad. 
I do not think it can be fixed inside the autonomous AP/client model, 
even with wired Ethernet backhaul.

The architectural question is whether an effective cost function can be 
made observable and actionable by moving MAC decisions to a point with 
enough shared state, and by providing a fronthaul that enables this cost 
function analysis in near real time.

Bob


> Sebastian Moeller via Bloat wrote:
> 
>> the point is current WiFi sucks under staturating loads, period.
> 
> This is correct and I doubt that it can be fixed.
> 
> Wifi was designed for a different era. I remember renting a pcmcia card 
> for a conference with a $800 deposit because that was the purchase 
> price for the card. Wifi was expected to be something rare and the 
> protocol reflects that.
> 
> In an environment where there are only a few statinos, the retry and 
> then retry at a slower data rate do work, and the slower data rate is 
> more likely to be deciphered if the problem is a weak signal or high 
> noise level
> 
> but today you only see such environments in a lab, on a farm, or 
> possibly a large estate.
> 
> In the more common conditions today where airtime is the limiting 
> factor and hidden transmitters (where the receiving station can hear 
> two stations that can't hear each other) are the rule rather than the 
> exception, having to retransmit everything when you are stepped on 
> because the receiving station can't validate anything it heard if it 
> doesn't hear the complete transmission wastes airtime, and transmitting 
> at a lower data rate will make it more likely that you get stepped on, 
> not more likely that you will get your message through
> 
> this leads to performance falling off a cliff when the available 
> airtime fills up rather than graceful degredation
> 
> If the next wifi standard could have checksums at various places during 
> the broadcast, it would be possible for part of the data to get 
> through, and get acked and normal tcp retries to get the rest 
> transmitted later. Combine this with NOT slowing down when you have 
> trouble getting through would help greatly reduce this cliff (as long 
> as your signal strength is high enough, acks from the AP would have to 
> report how they hear you)
> 
> but without coordination between the stations that can't hear each 
> other, you can't fix the hidden transmitter problem.
> 
> you can somewhat mitigate it if you have lots of APs and you set the 
> APs to only pay attemtion to signals that are pretty strong. If you 
> tune this just exactly right you can make it so the stations at 
> opposite sides of you can hear each other to avoid collisions. This 
> tuning would be very difficult to get right.
> 
> the only theoretical answer to the problem is to have the AP manage 
> transmission slots, but that doesn't work very well in practice (the 
> management eats so much airtime that the 'dumber' design wins with 
> higher throughput, up until total collapse.
> 
> 
> 
> getting cake to be able to adjust to changing bandwidth would help 
> avoid driving the network to saturation, but being able to deploy more 
> APs to use more channels at lower power is adding additional airtime, 
> pushing the limit futher out. It's not the best solution, it just works 
> in practice (most of the time)
> 
> David Lang