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 52EDC10F2054; Fri, 15 May 2026 15:57:58 +0200 (CEST) Received: from [10.2.3.133] (unknown [10.2.3.133]) by mail.lang.hm (Postfix) with ESMTP id 61ED3224E1C; Fri, 15 May 2026 06:57:57 -0700 (PDT) Date: Fri, 15 May 2026 06:57:52 -0700 (MST) From: David Lang To: bob.mcmahon@umbernetworks.com cc: David Lang , Frantisek Borsik , Cake List , Make-Wifi-fast , bloat , Jeremy Austin via Rpm , codel@lists.bufferbloat.net, "Dave.seddon Ca" , William Fisher , Igor Aleinikov , Jim , Jiml , Douglas Fairbairn , Thomas , Tim Odriscoll , Morten , Sebastian Moeller , Mt Denicolo , Mmcmahon01 , Santanu Sinha , Matthew In-Reply-To: Message-ID: References: <709dac7800ee7ad92aafd4eab1c761d9@umbernetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Message-ID-Hash: ZCGWQ5WBZ65DQEXZNPJTT5CQCQYBGC5O X-Message-ID-Hash: ZCGWQ5WBZ65DQEXZNPJTT5CQCQYBGC5O 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: [Codel] Re: [Cake] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon List-Id: CoDel AQM discussions Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: bob.mcmahon@umbernetworks.com wrote: > On dawn/usteer and 802.11r/k: these are steering protocols layered on top of > CSMA/CA. They help clients find a better AP but each AP still contends > independently for the medium. No global scheduler, no coordinated > transmission, no spatial stream coordination across RRHs. These systems > improve client placement within a distributed contention architecture. Fi-Wi > instead centralizes airtime scheduling itself. > > On what improves first and is measurable: roaming latency drops to near zero > because association never changes. Hidden node problems disappear because > there is no contention. MU-MIMO utilization becomes a scheduling decision > rather than a statistical outcome. Deterministic latency, which 802.11 cannot > guarantee by design, becomes a first-class deliverable. Those are the metrics > we will be publishing from real building deployments through this year. I get the difference now, scheduling all RF transmissions across all devices from ne central system, that's ambitious and seems like it would hae scaling problems (even just the metadata is a lot of informatin to run through a single system with very tight timing requirements) You speak of fiber to the room, but that doesn't seem to be the trend that I see. I see less interest in connections to rooms (fiber or copper), with 'everyone will just use wifi', and reluctance to wire for the APs. I would love it if you had the fantastic capabilities to all the appropriate AP locations (it doesn't help that the 'enterprise' vendors tell them to just put in a small number of their multi-radio/multi-antenna/zoned APs to cover everything) at best, you can end up controlling the AP transmissions of your APs. you can't control the client transmission scheduling, and you can't control other systems (upstairs/downstairs/adjacent neighbors, personal hotspots, etc) the RF environment also changes depending on doors open, temporary furniture, room occupation, etc. You will not only need a lot of control of the transmitters, but you will also need a lot of receiving stations listening to the spectrum to hear what else is out there. This is possible with software defined radio receiviers, but not easy due to the very wide bandwidth that needs to be monitored. On top of this, you aren't talking about one plane of RF, you have lots of them, one per channel, just minimizing co-channel interference by allocating the channels properly does wonders for performance, but is a rather hard real-world problem in the changing rf environment. Depending on if you can use DFS channels and what channel width you provide, (are you optimizing for a small number of high bandwidht clients, or a large number of lower bandwidth clients) the number of RF planes to optimize can vary. I find that lots of narrow channels re-used at close distances works well for conference type settings (even without 802.11k/r). My biggest problem is clients that don't want to cooperate (apple being a big one) interesting, but still a bit skeptical that this is a problem that can be knowable enough to try to implement a global scheduler for. David Lang