CoDel AQM discussions
 help / color / mirror / Atom feed
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: [Codel] Re: [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

  reply	other threads:[~2026-05-19 22:45 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-14 16:46 [Codel] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon Frantisek Borsik
2026-05-14 17:08 ` [Codel] 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             ` [Codel] Re: [Bloat] " 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

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/codel.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