From: bob.mcmahon@umbernetworks.com
To: David Lang <david@lang.hm>
Cc: "Livingood, Jason" <Jason_Livingood@comcast.com>,
Frantisek Borsik <frantisek.borsik@gmail.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: [Bloat] Re: [Cake] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon
Date: Tue, 19 May 2026 15:45:14 -0700 [thread overview]
Message-ID: <f762d3cc760d60deea7d74adf563ce37@umbernetworks.com> (raw)
In-Reply-To: <0oq1n88q-36qn-p6s7-699s-p4nr0440p950@ynat.uz>
> 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
next prev parent reply other threads:[~2026-05-19 22:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-14 16:46 [Bloat] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon Frantisek Borsik
2026-05-14 17:08 ` [Bloat] Re: [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 ` Livingood, Jason
2026-05-19 18:59 ` David Lang
2026-05-19 22:45 ` bob.mcmahon [this message]
2026-05-21 19:42 ` Frantisek Borsik
2026-05-21 20:02 ` dan
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/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f762d3cc760d60deea7d74adf563ce37@umbernetworks.com \
--to=bob.mcmahon@umbernetworks.com \
--cc=Jason_Livingood@comcast.com \
--cc=bloat@lists.bufferbloat.net \
--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