From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass smtp.mailfrom=lang.hm; dkim=fail; arc=none (Message is not ARC signed); dmarc=none Received: from mail.lang.hm (wsip-70-167-213-146.ph.ph.cox.net [70.167.213.146]) by mail.toke.dk (Postfix) with ESMTPS id 199AA11D6C28; Mon, 08 Jun 2026 05:59:21 +0200 (CEST) Received: from [10.2.3.133] (unknown [10.2.3.133]) by mail.lang.hm (Postfix) with ESMTP id 0FED3227929; Sun, 7 Jun 2026 20:59:20 -0700 (PDT) Date: Sun, 7 Jun 2026 20:59:15 -0700 (MST) From: David Lang To: bob.mcmahon@umbernetworks.com cc: David Lang , Sebastian Moeller , Frantisek Borsik , codel@lists.bufferbloat.net, dan , Cake List , Make-Wifi-fast , bloat , Jiml , William Fisher , Thomas , Tim Odriscoll In-Reply-To: Message-ID: <04196260-1r1n-3qpr-39qs-7r40p1183s5o@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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Message-ID-Hash: EXRBIKW36PCO2Q6T4CWBAKV44SKF76FJ X-Message-ID-Hash: EXRBIKW36PCO2Q6T4CWBAKV44SKF76FJ X-MailFrom: david@lang.hm X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header 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: bob.mcmahon@umbernetworks.com wrote: > 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. agreed, although the conference environment I support at Scale is pretty close to the limit (150 people in a room all using their laptops and phones) > 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. you may be able to make a dent in the AP use of airtime, but how are you going to coordinate the wifi devices you are talking to that are using so much of it, and doing most of the hidden transmitter stomping on each other? you can do channel allocation and lower the AP power to reduce (and if you can use DFS channels almost eliminate) the APs stepping on each other, but doesn't solve the mobile device coordination. David Lang