From: David Lang <david@lang.hm>
To: bob.mcmahon@umbernetworks.com
Cc: David Lang <david@lang.hm>, Sebastian Moeller <moeller0@gmx.de>,
Frantisek Borsik <frantisek.borsik@gmail.com>,
codel@lists.bufferbloat.net, dan <dandenson@gmail.com>,
Cake List <cake@lists.bufferbloat.net>,
Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>,
bloat <bloat@lists.bufferbloat.net>, Jiml <jiml@quicksmart.com>,
William Fisher <zzyzxr99@gmail.com>, Thomas <thomas@monjalon.net>,
Tim Odriscoll <tim.odriscoll@intel.com>
Subject: [Make-wifi-fast] Re: [Bloat] Re: [Codel] [Rpm] Re: Re: [Cake] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon
Date: Sun, 7 Jun 2026 20:59:15 -0700 (MST) [thread overview]
Message-ID: <04196260-1r1n-3qpr-39qs-7r40p1183s5o@ynat.uz> (raw)
In-Reply-To: <c6d77d510a14f0d484c837d8bf61992c@umbernetworks.com>
bob.mcmahon@umbernetworks.com wrote:
> The cliff behavior under saturation is real, and retry/rate fallback can make
> it worse. Lower MCS consumes more airtime, which increases collision
> exposure, which drives more retries and more fallback. All degrading tail
> latencies and, hence, user experience.
>
> I think the deeper problem is that conventional Wi-Fi has no shared airtime
> cost function. Each AP and client makes local decisions from partial
> information: CCA, retries, RSSI, rate control, EDCA backoff, and local queue
> state. But no one has enough shared state to ask what a transmission actually
> costs right now in airtime, collision risk, retry probability, and delay
> imposed on other flows.
>
> That is why more APs at lower power helps but does not fundamentally solve
> the problem. It adds spatial reuse and pushes the cliff farther out, but each
> node is still guessing about a medium it can only partially observe. And the
> number of devices keeps growing and growing.
agreed, although the conference environment I support at Scale is pretty close
to the limit (150 people in a room all using their laptops and phones)
> The distinction I would draw is between scheduling over the contested RF
> medium and scheduling with an out-of-band coordination path. In-band
> scheduling burns the same airtime it is trying to preserve. Out-of-band
> scheduling changes that cost model, but only if the fronthaul satisfies some
> hard requirements: bounded worst-case latency so grants arrive before slots
> open, no contention on the control path, and enough bandwidth to carry both
> queue state and PHY state (RSSI, ED, MCS, spatial stream availability) back
> to the scheduler continuously. Without PHY state the scheduler knows who has
> data waiting but not what each transmission will cost in airtime or impose on
> tail latencies.
>
> So I agree that current Wi-Fi under saturating load is structurally bad. I do
> not think it can be fixed inside the autonomous AP/client model, even with
> wired Ethernet backhaul.
>
> The architectural question is whether an effective cost function can be made
> observable and actionable by moving MAC decisions to a point with enough
> shared state, and by providing a fronthaul that enables this cost function
> analysis in near real time.
you may be able to make a dent in the AP use of airtime, but how are you going
to coordinate the wifi devices you are talking to that are using so much of it,
and doing most of the hidden transmitter stomping on each other? you can do
channel allocation and lower the AP power to reduce (and if you can use DFS
channels almost eliminate) the APs stepping on each other, but doesn't solve the
mobile device coordination.
David Lang
next prev parent reply other threads:[~2026-06-08 3:59 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-14 14:40 [Make-wifi-fast] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon Frantisek Borsik
2026-05-14 17:08 ` [Make-wifi-fast] Re: [Cake] " David Lang
2026-05-14 15:20 ` 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 ` [Make-wifi-fast] 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
2026-05-22 16:36 ` [Make-wifi-fast] Re: [Rpm] " Robert McMahon
2026-05-23 2:18 ` dan
2026-05-23 16:36 ` bob.mcmahon
2026-05-23 22:12 ` dan
2026-05-24 20:06 ` Frantisek Borsik
2026-05-24 21:57 ` bob.mcmahon
2026-05-25 5:43 ` Frantisek Borsik
2026-05-25 6:58 ` [Make-wifi-fast] Re: [Codel] " Sebastian Moeller
2026-05-25 12:45 ` Frantisek Borsik
2026-05-25 13:36 ` [Make-wifi-fast] Re: [Codel] " Sebastian Moeller
2026-06-07 6:15 ` Frantisek Borsik
2026-06-07 9:03 ` Sebastian Moeller
2026-06-07 10:19 ` [Make-wifi-fast] Re: [Bloat] Re: [Codel] [Rpm] " David Lang
2026-06-07 18:10 ` bob.mcmahon
2026-06-07 18:30 ` dan
2026-06-07 19:10 ` bob.mcmahon
2026-06-08 0:29 ` dan
2026-06-08 2:55 ` bob.mcmahon
2026-06-08 4:06 ` David Lang
2026-06-08 6:26 ` [Make-wifi-fast] Re: [Bloat] " Sebastian Moeller
2026-06-08 3:59 ` David Lang [this message]
2026-06-08 5:18 ` [Make-wifi-fast] Re: [Bloat] " bob.mcmahon
2026-06-08 6:53 ` David Lang
2026-06-08 10:29 ` Frantisek Borsik
[not found] ` <e68abec2-6fd8-4fc4-ad26-5ca10859551c@rogers.com>
2026-06-09 3:40 ` [Make-wifi-fast] Re: [Codel] Re: [Bloat] " bob.mcmahon
2026-06-07 6:49 ` [Make-wifi-fast] Re: [Bloat] Re: [Codel] " David Lang
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/make-wifi-fast.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=04196260-1r1n-3qpr-39qs-7r40p1183s5o@ynat.uz \
--to=david@lang.hm \
--cc=bloat@lists.bufferbloat.net \
--cc=bob.mcmahon@umbernetworks.com \
--cc=cake@lists.bufferbloat.net \
--cc=codel@lists.bufferbloat.net \
--cc=dandenson@gmail.com \
--cc=frantisek.borsik@gmail.com \
--cc=jiml@quicksmart.com \
--cc=make-wifi-fast@lists.bufferbloat.net \
--cc=moeller0@gmx.de \
--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