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 9AA5910F296B; Fri, 15 May 2026 17:18:01 +0200 (CEST) Received: from webmail.umbernetworks.com (files.umbernetwork.com [198.74.51.139]) by mail.umbernetworks.com (Postfix) with ESMTPA id 1061B21A372; Fri, 15 May 2026 15:17:59 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 15 May 2026 17:17:58 +0200 From: bob.mcmahon@umbernetworks.com To: David Lang Cc: 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: References: <709dac7800ee7ad92aafd4eab1c761d9@umbernetworks.com> 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: H5QQVDS4HUUVIFYN4VTHVTRCQ57L4JHA X-Message-ID-Hash: H5QQVDS4HUUVIFYN4VTHVTRCQ57L4JHA X-Mailman-Approved-At: Fri, 15 May 2026 22:16:51 +0200 X-Mailman-Version: 3.3.10 Precedence: list Subject: [Bloat] Re: [Cake] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon List-Id: General list for discussing Bufferbloat Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: > 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, The winmodem analogy is apt. Thanks for bringing it up. The pattern is consistent: move complexity from dedicated silicon to CPU. We win when the CPU gets fast enough. DPDK on a Threadripper PRO with 128 PCIe lanes is that moment for wireless scheduling. On perfect knowledge: IP routing operates on incomplete topology information and converges. TCP congestion control has no direct visibility into queue state along the path and delivers traffic. BGP makes forwarding decisions on stale information and the internet functions. In each case the system improves as information quality increases, which is exactly what L4S marking does for congestion control. The question has never been whether the knowledge is perfect. It is whether the system is robust to imperfect information and whether it outperforms even with that imperfection. Fi-Wi's fallback is always CSMA/CA. Any improvement over that baseline under real conditions is a measurable win. The Fi-Wi architecture provides materially more global state than independently operating APs have today. The scheduler does not need a perfectly knowable RF environment, just a materially better one. The fiber run is to the RRH. The end device still uses Wi-Fi. 25B devices stay as they are. Uncooperative clients fall back to CSMA/CA. The downlink scheduling advantage and coordinated transmitter picture still apply. And because collision probability increases superlinearly with contention density in CSMA/CA systems, even partial scheduling reduces contention pressure for the remaining CSMA/CA traffic disproportionately. Coordinated infrastructure reduces load on the shared medium even for unmanaged clients. For the 25B existing devices, the infrastructure controls more than most deployments use today: o) CTS-to-self creates protected transmission windows across managed RRHs o) Adaptive EDCA and TXOP policies bias contention behavior dynamically o) TCP ACK scheduling at the concentrator shapes STA transmission behavior through the transport layer without requiring 802.11-layer changes o) Transport signals are bidirectional. L4S ECN marking and TCP Prague congestion responses create a control loop between the concentrator and STAs that influences client behavior from above the wireless layer. An L4S-aware STA running TCP Prague is participating in the scheduling loop whether or not it knows anything about Fi-Wi. o) L4S visibility into the Wi-Fi link is critical when wireless is the bottleneck, which in a building deployment it almost always is. ECN marking at the concentrator makes that bottleneck visible to the transport layer for the first time, allowing TCP Prague to respond precisely rather than reactively. Today that information is lost inside opaque firmware scheduling and media access decisions. o) UL-OFDMA trigger frames direct uplink transmission timing for the growing 802.11ax installed base On RF variability: every RRH not carrying a transmission is either a receiver feeding aggregate channel state back to the concentrator, or can contribute spatial suppression via beamforming where supported. Building RF conditions are also learnable over time. CSI across all RRHs captures how the environment changes with occupancy, time of day, and physical configuration. The concentrator builds a temporal model of the building that improves scheduler decisions continuously. An autonomous AP has no such memory. On channel management: dense narrow channel reuse works well. Experienced operators are already doing this manually. The goal is to make those decisions dynamic and scheduler-driven rather than static planning assumptions. One underappreciated fact: 802.11 EDCA values were never meant to be constants. They were placeholder examples, with the expectation that a BSS manager would adapt them to real conditions. That BSS manager was never built because there was no centralized view of the RF environment to build it from. The placeholders became the standard. Fi-Wi directly addresses this. The EDCA policies become scheduler-driven rather than static firmware constants. The RRHs become nodes. The scheduler defines the edges, which radios serve which clients, on which channels, at which MCS, in which time slots. 802.11 hardware vendors have been making those decisions independently, each without any knowledge of the others, because there was no fronthaul architecture to make a shared view practical. The real question is not whether we can fully model RF. It is whether centralized partial-state coordination produces measurably better latency distributions, airtime utilization, and roaming continuity than distributed partial-state contention under real RF conditions and bounded observability. That is a testable hypothesis. That is what we are validating in real building deployments through this year, focusing on latency distribution under load, MU-MIMO utilization, and roaming continuity. This is a lot of work. A property of new industry. Bob