From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass smtp.mailfrom=; dkim=fail; arc=none (Message is not ARC signed); dmarc=fail (Used From Domain Record) header.from=umbernetworks.com policy.dmarc=quarantine Received: from mail.umbernetworks.com (mail.umbernetworks.com [198.74.51.139]) by mail.toke.dk (Postfix) with ESMTPS id 2B59A11D38DD; Sun, 07 Jun 2026 20:10:32 +0200 (CEST) Received: from webmail.umbernetworks.com (files.umbernetwork.com [198.74.51.139]) by mail.umbernetworks.com (Postfix) with ESMTPA id AF6F521399F; Sun, 07 Jun 2026 18:10:30 +0000 (UTC) MIME-Version: 1.0 Date: Sun, 07 Jun 2026 11:10:30 -0700 From: bob.mcmahon@umbernetworks.com To: David Lang Cc: Sebastian Moeller , Frantisek Borsik , codel@lists.bufferbloat.net, dan , Cake List , Make-Wifi-fast , bloat , Jiml , William Fisher , Thomas , Tim Odriscoll In-Reply-To: <8qr7qons-5sp9-o30o-49qr-02p67prss6rr@ynat.uz> References: <8e14c6935753c6263351ad00ec59b9cb@umbernetworks.com> <055e42685cddfa4c1a4ff4da089996eb@umbernetworks.com> <7455E3B4-7FB4-4D40-A900-B31151D12F6F@gmx.de> <52CE3DA7-EC5A-4FF8-A88E-26A7A6661983@gmx.de> <8qr7qons-5sp9-o30o-49qr-02p67prss6rr@ynat.uz> Message-ID: X-Sender: bob.mcmahon@umbernetworks.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-MailFrom: bob.mcmahon@umbernetworks.com X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation Message-ID-Hash: 3BX7DVY5REJIY53BVNFY7NW5EZQJSDNU X-Message-ID-Hash: 3BX7DVY5REJIY53BVNFY7NW5EZQJSDNU X-Mailman-Approved-At: Mon, 08 Jun 2026 12:36:15 +0200 X-Mailman-Version: 3.3.10 Precedence: list Subject: [Make-wifi-fast] Re: [Bloat] Re: [Codel] [Rpm] Re: Re: [Cake] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon List-Id: Lets make wifi fast again! Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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