Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: dan <dandenson@gmail.com>
To: Frantisek Borsik <frantisek.borsik@gmail.com>
Cc: bob.mcmahon@umbernetworks.com, David Lang <david@lang.hm>,
	"Livingood, Jason" <Jason_Livingood@comcast.com>,
	Cake List <cake@lists.bufferbloat.net>,
	Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>,
	bloat <bloat@lists.bufferbloat.net>,
	Jeremy Austin via Rpm <rpm@lists.bufferbloat.net>,
	codel@lists.bufferbloat.net,
	"Dave.seddon Ca" <dave.seddon.ca@gmail.com>,
	William Fisher <zzyzxr99@gmail.com>,
	Igor Aleinikov <igor.aleinikov@adnacom.com>,
	Jim <jim@iniholdings.com>, Jiml <jiml@quicksmart.com>,
	Douglas Fairbairn <dfairbairn@megachips.com>,
	Thomas <thomas@monjalon.net>,
	Tim Odriscoll <tim.odriscoll@intel.com>,
	Morten <morten@broerup.com>,
	Sebastian Moeller <sebastian.moeller@gmail.com>,
	Mt Denicolo <mt.denicolo@gmail.com>,
	Mmcmahon01 <mmcmahon01@gmail.com>,
	Santanu Sinha <santanusinha@yahoo.com>,
	Matthew <matthew@mteley.com>, Koen DS <koen0607@gmail.com>,
	Shotaro Saito <ssaito@megachips.com>
Subject: [Cake] Re: [Bloat] Re: "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon
Date: Thu, 21 May 2026 14:02:21 -0600	[thread overview]
Message-ID: <CAA_JP8XE9cuJDD+PjOiYYvZRAADrPua7e68EmrQQX=7Op-6VKg@mail.gmail.com> (raw)
In-Reply-To: <CAJUtOOgRnf51JWOgvS0oGc1iuqHKMfbn5TtNTJaQfZc7J7nALg@mail.gmail.com>

On Thu, May 21, 2026 at 1:36 PM Frantisek Borsik
<frantisek.borsik@gmail.com> wrote:
>
> Saw this one from Bob on LinkedIn - maybe there is someone interested lurking 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 powers the remote radio head. The job is to cut to length from a 1000 ft spool, terminate with a pigtail, and verify optical power and low-voltage delivery before units go out.
>
> The Meta Level Up training is free. Umber will provide the splicing and power-testing equipment. First units and our power distribution system should be ready by late summer."
>
> https://www.linkedin.com/posts/robert-bob-mcmahon-b1a42a1_levelup-fiber-technician-pathway-meta-data-activity-7463251969630097408-AcWJ?
>
> All the best,
>
> Frank
>
> Frantisek (Frank) Borsik
>
>
> In loving memory of Dave Täht: 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 AM <bob.mcmahon@umbernetworks.com> 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.

      reply	other threads:[~2026-05-21 20:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-14 16:46 [Cake] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon Frantisek Borsik
2026-05-14 17:08 ` [Cake] " David Lang
2026-05-14 17:26   ` Frantisek Borsik
2026-05-14 19:38     ` bob.mcmahon
2026-05-14 19:55       ` David Lang
2026-05-15 11:11         ` bob.mcmahon
2026-05-15 13:57           ` David Lang
2026-05-15 14:18             ` David Lang
2026-05-15 15:17             ` bob.mcmahon
2026-05-19 13:52             ` [Cake] Re: [Bloat] " Livingood, Jason
2026-05-19 18:59               ` David Lang
2026-05-19 22:45                 ` bob.mcmahon
2026-05-21 19:42                   ` Frantisek Borsik
2026-05-21 20:02                     ` dan [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAA_JP8XE9cuJDD+PjOiYYvZRAADrPua7e68EmrQQX=7Op-6VKg@mail.gmail.com' \
    --to=dandenson@gmail.com \
    --cc=Jason_Livingood@comcast.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=bob.mcmahon@umbernetworks.com \
    --cc=cake@lists.bufferbloat.net \
    --cc=codel@lists.bufferbloat.net \
    --cc=dave.seddon.ca@gmail.com \
    --cc=david@lang.hm \
    --cc=dfairbairn@megachips.com \
    --cc=frantisek.borsik@gmail.com \
    --cc=igor.aleinikov@adnacom.com \
    --cc=jim@iniholdings.com \
    --cc=jiml@quicksmart.com \
    --cc=koen0607@gmail.com \
    --cc=make-wifi-fast@lists.bufferbloat.net \
    --cc=matthew@mteley.com \
    --cc=mmcmahon01@gmail.com \
    --cc=morten@broerup.com \
    --cc=mt.denicolo@gmail.com \
    --cc=rpm@lists.bufferbloat.net \
    --cc=santanusinha@yahoo.com \
    --cc=sebastian.moeller@gmail.com \
    --cc=ssaito@megachips.com \
    --cc=thomas@monjalon.net \
    --cc=tim.odriscoll@intel.com \
    --cc=zzyzxr99@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox