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 49A0811D6686; Mon, 08 Jun 2026 04:55:50 +0200 (CEST) Received: from webmail.umbernetworks.com (files.umbernetwork.com [198.74.51.139]) by mail.umbernetworks.com (Postfix) with ESMTPA id DDEB1214A42; Mon, 08 Jun 2026 02:55:47 +0000 (UTC) MIME-Version: 1.0 Date: Sun, 07 Jun 2026 19:55:47 -0700 From: bob.mcmahon@umbernetworks.com To: dan Cc: David Lang , Sebastian Moeller , Frantisek Borsik , codel@lists.bufferbloat.net, Cake List , Make-Wifi-fast , bloat , Jiml , William Fisher , Thomas , Tim Odriscoll In-Reply-To: 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> <7421a405a482f9a38f100f31979b2a7c@umbernetworks.com> Message-ID: <1f8899159131552b8c578c5865d86832@umbernetworks.com> X-Sender: bob.mcmahon@umbernetworks.com 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: QWJJCPG5YX7ARV7MAJZXLEPWTP26NWWT X-Message-ID-Hash: QWJJCPG5YX7ARV7MAJZXLEPWTP26NWWT X-Mailman-Approved-At: Mon, 08 Jun 2026 12:36:17 +0200 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed X-Content-Filtered-By: Mailman/MimeDel 3.3.10 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 Dan, 802.11 will not define a building-wide control plane, a building-wide BSS manager, or a shared cost function. That architecture is outside the scope of the 802.11 standards and contrary to the AP vendors' business models. Replacing the client base is a non-starter. Tenants, guests, IoT vendors, phones, cameras, laptops, and embedded devices arrive on their own schedules. The building has to work with the devices that show up, not the devices standards bodies, vendors and service providers wish would show up. User experience is fundamentally defined by tail latency. The standards bodies and AP vendors have optimized Wi-Fi for capacity, not service-time control. A-MPDU is the most obvious example: larger aggregates improve throughput by amortizing contention and PHY overhead, but they also concentrate airtime into longer bursts. During that burst, the AP is committed to one transmission or reception and cannot serve other clients; every device trying to transmit through that AP to the WAN link has to wait. The same burst also creates interference energy for other BSSs that can hear it, lowering SINR while the transmission is active. The current system treats a larger aggregate as a capacity win even when it creates the tail-latency loss that drives customer complaints to the internet service provider. The MCS index table makes the same point from the PHY side. A packet's airtime cost depends on MCS, channel width, spatial streams, guard interval, retries, and receiver conditions. But 802.11 leaves EDCA, MCS/rate control, scheduling policy, aggregation policy, and airtime tradeoffs inside autonomous, vendor-specific AP firmware. Operators cannot know, verify, or control those decisions. What is missing are a few things. First, the interference graph: what one transmission costs the rest of the managed domain in other radios, other clients, other flows, retry probability, service-time variance, SINR impact, and tail-latency impact. Second, a building-wide BSS manager with authority to act across APs, BSS membership, channel and power policy, scheduling policy, aggregation policy, and airtime-cost enforcement. Third, ECN marking tied to scheduler-determined AMPDU aggregation on the WLAN side, coupled to WAN congestion and pacing signals. If control decisions remain inside autonomous, vendor-specific AP firmware, the system cannot have a building-wide wireless forwarding plane. Waiting for 802.11 to define that architecture is Waiting for Godot. Solving it requires moving radio-resource control behind the fronthaul into a central concentrator. Bob > WiFi and FiWi are following identical RF standards, there is no > argument between the two on this. ie the OFDMA arguments. > > OFDMA does wait PER RU for CS, but only per RU, it can transmit on > clean RUs per AP. This is practically identical to FiWi's featureset > because it's also using OFDMA with CS protection on WiFi7 FiWi. There > is no advantage to FiWi here, we're all talking OFDMA to OFDMA clients. > > I'll acknowledge 2.5 REAL FiWi advantages. Sorted by value in my eyes > > 1) combining a single client transmission received on multiple RRH > additively. Sort of 'beamforming advantage'. WiFi will likely never > gain such a feature. WiFi 9+ should get virtual AP which will look a > lot like this, but FiWi would likely always retain an edge here and > it's available *today*, likely...5-10 years out for wifi9 and this > feature. > > 2) single presented MAC. Clients don't have to 'roam' within RRH > groups. WiFi has r/k/v roaming which is fantastic, but it is a > mechanism that requires client support. Newer WiFi devices all have > this so it's a disadvantage that fades a bit over time, but FiWi would > always retain an edge here. > > 3) central scheduling. FiWi with a central controller acts as one > giant MuMIMO AP *today*. WiFi was supposed to get this in 7, but it > got pushed to 8. WiFi8 does have central management and scheduling > available and that is in draft hardware today. This is the '0.5' of > the 2.5 advantages. > > HOWEVER, my original point is that WiFi7 today fill the vast majority > of the FiWi performance claims when the network is built and planned > well. Practical deployments, not quoting paper specs. Again, we're > doing event centers, hotels, etc and WiFi7 is like magic today, > cheaply. > > I'll give a specific example here that presents a challenge that FiWi > cannot practicaly service (the fiber to the RRH being the eliminator > here). We run a network is a small resort town with seamless WiFi > along the entire 1/2 mile downtown area including parts and > storefronts, the zoo, etc. We run my favorite SIP phone, the Yealink > AX86R and you can walk 3 major paths and probably 20 solid minutes on > foot roaming via r/k/v, with prioritized packets, riding a network with > many wifi cameras and often many hundreds of users, and seamlessly roam > through a dozen restaurants and a couple hotels, without a hiccup. > This traverses a VLAN over multiple mmWave wireless links building a > ~4Gbps mesh fabric. Modern WiFi phones pull >1G speed tests, there are > no congestion issues even during peak season. These APs have a public > SSID. WiFi7 KILLS. Same story as above, WPA3/80Mhz channels in 5Ghz, > 160Mhz in 6Ghz, makes for an almost entirely OFDMA capable device > makeup. Separate APs on WPA 2.4/5Ghz in buildings to facilitate > legacy. This is a 'very hard' wifi thing in the old days and today, > it's actually quite easy. And mind you, these are outdoor APs, > they're fighting consumer wifi noise much much more than typical. > They have to schedule around self-noise. Also note, this net runs > cellular offload so we have a LOT of 'drive-by' joins and use. > > OFDMA actually *is* a magic bullet for WiFi, but the anecdotal evidence > given is *1* OFDMA bullet in a six shooter and the other 5 are 802.11n. > You cannot make strong judgements on modern wifi if you're not > building modern wifi networks. > > The original premise IMO stands, modern WiFi, especially in deployments > that are FiWi targets, is already very very very good in real world > deployments.