From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass smtp.mailfrom=; dkim=pass header.d=gmail.com; arc=pass; dmarc=pass (Used From Domain Record) header.from=gmail.com policy.dmarc=quarantine Received: from mail-dy1-x1333.google.com (mail-dy1-x1333.google.com [IPv6:2607:f8b0:4864:20::1333]) by mail.toke.dk (Postfix) with ESMTPS id 793B7113B72D for ; Thu, 21 May 2026 22:02:36 +0200 (CEST) Received: by mail-dy1-x1333.google.com with SMTP id 5a478bee46e88-2f68f3b075fso5501550eec.0 for ; Thu, 21 May 2026 13:02:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779393754; cv=none; d=google.com; s=arc-20240605; b=MIg9m137BJyBLPvz7pzD5VCSMndkdwEdzXWeODipFBNeTOjFeet3ncY7njtnM55X75 Fx2OTyZA2vekc77kNKM6+ARRpMwd+sFkKf8wj7nAxqHHI1z1ut+5pU6nUz8trv5puSOf tXEFFac4ctp5eJhNMgXxMBMB2bDDdbL/J164TX0iu4CCYOCVH/tieHnLOKsLrvevYqW1 gJYZlpvH3xjgpPoaKpIiqKbCUGluxJhSHt46TixQy78TOWANZtljdr2bzSmksTxmxwL7 w3zdcj3eAnQ0IRgy/GACrBJ12HpdvOjQmaLHgUGx47GNKHokj9Q6VTvYyO/RPeL+KtY/ spQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=YhGxQUVTR+0Ang4kk5v36pZiaYpLZrDb+N2nZzU3jbI=; fh=+LXoGibQN9OOo06fIS31tHdiwTGKQuTkU5u2gpQe5mY=; b=ceaMPqfkTjo3q8SnEKYXcxE+31qu9WW/e6SacUNkHzQlZA8sZTAHEasxcO1DzV5flA EJ4pWE6Dl1ewZDPAa34lIasRW2XYfEsJIsObelq/IS6pJK8b9o0aRLshebc0ydeH1hSc KnBnXNwNcY9SwVjI/XPRLpYwtLL8WBJ+djGNMrOkSJdTludFakSUX+O7SM0VNP3UEFSH tnq/Gle6DWWHjnCgxKEKjEttAbry8r9HkPb7H0S0ZXB/0Q1x3kjUbOecUmVUG68EAwn/ 57n3cYCxfTUCwSXxg5DgrdUjC77friTqSRyNO9/ovspjdru7EuPQSBlNVahXBPtIukKm y5XQ==; darn=lists.bufferbloat.net ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779393754; x=1779998554; darn=lists.bufferbloat.net; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=YhGxQUVTR+0Ang4kk5v36pZiaYpLZrDb+N2nZzU3jbI=; b=MFkn0RAOJsVhOXlrB8Pk/bkJf8ZqHWjkoqpQcO4ygDLZoPahoremr79YGLBOuZNvr+ 5lICd+Obupb7/NKpQFwQjL2mWs1GdYd9lFxzKgNk9V2RNBefdPvi+EFx9d+h2RB331lV NxfoxUdO/60/oyi3bp5p+NS/0g42ip6ZldXrrO+7IU4+v4YZx1yx0itCGX6zm1igHMKv eOGav+r4Umd0gw78bYdmXQt4dcjnf+Sf9k8fqOBxLgaACRTWmf6HJz/FQItaKOJVKfmU dB79MRj3ExVlglJZmAq8jCeAjV9Gitk827RVcoiAvSgO4wj+R97oX0R+JCVY5+9x8zFi d9DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779393754; x=1779998554; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=YhGxQUVTR+0Ang4kk5v36pZiaYpLZrDb+N2nZzU3jbI=; b=HMZEz9pjSGL6Tmp7Xa/4RdRFYAFfxndetcS9siiPjyokhzXQ5Pfi7a+uD3ZK8yuV13 hrs/iq+qAtdUm3lzZVhdzv1aeGa93ElOXWx7s+x1ErMFWvZDPwt8zp3XhHjtJoQKLrdS RaBWXCEBOp1nx1fiwToLItoVm/wMs3dHahdtw7/+j7KaHAJW/ox7bbsmK3z9KXQTfqZg 5yiRWrg+9FYiR4xURqHDNDwyIKPbFqczMcm3TJB+/NkbQciGgaesNSyV0z1Z/4jA6/bg UnYTUaMKYyBuqFY7u/Kgb2rJDV/IJRoTBZOS6pYtqetFl2yMScpcm+iLsptYy4xYHeFw 3+Gg== X-Forwarded-Encrypted: i=1; AFNElJ+V+HLBfMp3Z3EplMW3ARaeN2cgN5Cvq1MgfaLU5i7wBUZhtktV6S5X0Ja4l2NR0xGyFtU1rw==@lists.bufferbloat.net X-Gm-Message-State: AOJu0YwKt2LFB2mkayEQ9iJknKDxwD4ujeT7DehJZcRfGa5i/0AbKP0F fhw50dew0VcOTaJgSErS8QT6Yr/df61TCTVafrWizP10WyFm4KCch+q4q2GIGBl8nakzXScPrgx tJzuDMx15Olzn9xL00xVzGFT1FUyBjjQ= X-Gm-Gg: Acq92OHHMligIELccRc+sCtdDnLz308ORGcdgzKlTHZFTW9lCoempK67WspGk2C4HLA qsszCNFHd6J8eHwTVcflnSRQdja5RCfzVatUMwgnm2j8048O6SAfE3KAc9XpywICvNIapuWK34Y mTQE9RCL1ejiDP2iTPsfQ/jch6KbTBf+eJFxJbw+T/Zg5SLgkQ+aqfJyS3sPyx0yd5VNjivuePl eLe0TyaI41eJ2IqxutmewjgxEXdqTXoTBxp0N1XCRwyQs9Ej7DIwpQnWoDFSAvtSJop4suNF1cL 9V+bU2tfzeCGNOiY/XVIKe3GrFZJ9TFqfichKOaY X-Received: by 2002:a05:7300:dc83:b0:2c1:6676:5ebd with SMTP id 5a478bee46e88-3044902cee2mr406087eec.10.1779393753743; Thu, 21 May 2026 13:02:33 -0700 (PDT) MIME-Version: 1.0 References: <709dac7800ee7ad92aafd4eab1c761d9@umbernetworks.com> <0oq1n88q-36qn-p6s7-699s-p4nr0440p950@ynat.uz> In-Reply-To: From: dan Date: Thu, 21 May 2026 14:02:21 -0600 X-Gm-Features: AVHnY4KmglRwE1As-DcUvkOcmAqiaAqpkt4vLyM5zp5wHK3zPuT7Jkkl951Izh0 Message-ID: To: Frantisek Borsik Cc: bob.mcmahon@umbernetworks.com, David Lang , "Livingood, Jason" , 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 , Koen DS , Shotaro Saito Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: BKBD43AIDYBZ5XPDZ3XZXLRKRDJICM5Q X-Message-ID-Hash: BKBD43AIDYBZ5XPDZ3XZXLRKRDJICM5Q X-MailFrom: dandenson@gmail.com 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: [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: On Thu, May 21, 2026 at 1:36=E2=80=AFPM Frantisek Borsik wrote: > > Saw this one from Bob on LinkedIn - maybe there is someone interested lur= king here...: > > "Umber is looking for a Bay Area cable tech (contract, part-time to start= ) as we prepare to ship our UAX-8 concentrator. > > Each install uses a hybrid cable: dual fiber for data plus copper that po= wers the remote radio head. The job is to cut to length from a 1000 ft spoo= l, terminate with a pigtail, and verify optical power and low-voltage deliv= ery before units go out. > > The Meta Level Up training is free. Umber will provide the splicing and p= ower-testing equipment. First units and our power distribution system shoul= d be ready by late summer." > > https://www.linkedin.com/posts/robert-bob-mcmahon-b1a42a1_levelup-fiber-t= echnician-pathway-meta-data-activity-7463251969630097408-AcWJ? > > All the best, > > Frank > > Frantisek (Frank) Borsik > > > In loving memory of Dave T=C3=A4ht: 1965-2025 > > https://libreqos.io/2025/04/01/in-loving-memory-of-dave/ > > > https://www.linkedin.com/in/frantisekborsik > > Signal, Telegram, WhatsApp: +421919416714 > > iMessage, mobile: +420775230885 > > Skype: casioa5302ca > > frantisek.borsik@gmail.com > > > > On Wed, May 20, 2026 at 12:45=E2=80=AFAM = wrote: >> >> > the reason home wifi is so bad is because there is no coordination >> > between the wifi in the diffeent houses/apartments. you don't need to >> > tie all those devices into a single network to solve that, and unless >> > you do solve the coordination problem, there is no way for you to make >> > the rf environment better. >> > >> > coordination may only be an 80% solution compared to this, but 80% is = a >> > lot. >> > >> >> David, >> >> Even granting the 80% claim, which I don't think holds across 134M >> occupied homes in the US once you measure broadly enough, the loss >> functions shift dramatically with density, workload, and metric. >> Throughput, tail latency, and jitter under load do not degrade for the >> same reasons, and they do not reduce to a single number. >> >> Even inside a single home with one AP and no neighbors, Wi-Fi exhibits >> pathologies unrelated to cross-network coordination: hidden queues, >> retry storms, aggregation bursts, EDCA backoff variance, roaming >> decisions made with stale information, and firmware behavior the >> operator cannot observe or control. >> >> ECN marking, L4S, pacing, and AQMs all assume the layer below them >> provides observable and reasonably bounded service time. Conventional >> APs do not provide that. Coordinating neighbors does not fix it. >> >> The deeper problem is architectural. Conventional Wi-Fi scatters the >> observations. No AP sees enough state to make globally correct decisions >> across space, time, and frequency, so every AP treats overlap as loss >> and reacts using local, partial information. Neighbor coordination >> cannot recover information that was never collected, nor can it impose >> deterministic service intervals on autonomous 802.11 MAC state machines >> running in opaque vendor firmware. >> >> Fi-Wi inverts that architecture. The 802.11 MAC moves to the >> concentrator, where the observations are co-located and scheduling >> decisions are made in software the operator or building owner controls. >> The radios handle PHY/RF execution. One RRH or twenty, the architectural >> property is the same: airtime scheduling, transport feedback, and >> observability exist in one place. >> >> I put together a small animation showing how contention probability >> rises rapidly even with relatively small contention windows and moderate >> active station counts. It helps visualize why systems often become >> MAC-limited before PHY-limited: >> >> https://www.umbernetworks.com/csma-preview.html >> >> The "single network" is ultimately a human management abstraction. RF, >> like rats, does not respect property boundaries. The medium is shared >> whether or not the management plane pretends otherwise. Coordination >> between autonomous networks tries to paper over a partition we invented, >> and the ceiling is set by the partition. Fi-Wi doesn't eliminate the >> partition globally. It dissolves it within a coverage area, by replacing >> autonomous APs with radio arrays serving one MAC. Inside the domain, >> there is no partition to paper over. Engineering that matches physics is >> the goal. >> >> Bob We were having an offshoot conversation about this thread so I thought I'd pop in and add my 'boots on the ground' perspective. FiWi sounds great technology wise, however, WiFi has gotten very good and most of the benefits touted by FiWi are basically also in ultra-modern wifi. OFDMA is now standard in WiFi7+, so the CSMA argument is fading at a decent clip. Device churn puts more and more OFDMA capable devices on networks all the time. We're seeing conservatively 25% of connected clients having OFDMA capable radios, namely smart phones and laptops. Some days that number is much higher and there's a practical '5 year' window here on old tech for these devices. IoT devices and 'appliances' like printers will lag on much longer. Every new smartphone sold in the last 1-2 years already does it, and basically any laptop sold in the last year also. Splitting 2.4/5/6 into 2.4 legacy/IoT 'CSMA', then 5/6 in OFDMA works exceptionally well, and some enterprise APs have 2 5Ghz radios so you get 2.4/5 legacy + 5/6 OFDMA on different channels. Some enterprise APs can sync timing to improve re-use. A number of vendors offer directional (namely downwarn cone) antennas for spot coverage for scale And it's all on today's physical infrastructure, 1/2.5/5Gbps ports on enterprise APs and so on. Nothing stopping a WiFi AP from handling AQM, ECN, etc. CPUs *are* a bottleneck on cheaper APs, but on enterprise hardware they either have a fast enough CPU or they have a hardware offload for the radio/ethernet bridge. Any shortcoming here is IMO entirely based on the vendor's not believing the feature is worth implementing. MUMIMO on enterprise APs (with OFDMA) is fantastic and that really helps reduce co-interference. The one I guess 'unique' feature of the FiWi pitch that is unmatched (or unmatchable?) is scheduling transmission on the RRH that the system calculates is best for the receiver and that client device not really caring which 'AP' it comes from. ie, no Client:AP 1:1 association that relies on roaming for seamless coverage but is at the end of the day still 1:1. To me, this is really the only killer feature, and really it's probably something WiFi can and will implement in the future. I'm including client transmissions and redundancy handling in this piece too, killer feature, no reason standard WiFi can't do this in a future version that would potentially land before FiWi was a practical reality. However, my thought is that it will take far less time for all wifi client devices to be upgraded/replaced with OFDMA capable units. Fundamentally changing the way 'wifi/FiWi' is deployed in buildings with home-run fiber is likely extremely niche. In the market, the ad-hoc device model, even coordinated with a controller, has beaten out the centrally managed solution over and over. FiWi is mainframe-to-terminal/thin_client to WiFi's AP/thick_client model. I think that analogy would likely be how the market would look if FiWi were to proceed as some desire. I'd also argue that stand alone APs coordinated by a controller are a scale-out model. Putting cake on the wifi interfaces (which is NOT common....) scales cake out to the CPU on those APs instead of leaning on one central CPU. The WiFi model also is a bit more automatically redundant. Each AP can do 'everything' and the only thing at the core is a switch, and most enterprise APs have dual ports and can do some method of bonding/MLAGG/etc. VS a single core controller and RRH, a failure would seem a bit more catastrophic. Just thoughts though.