General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: bob.mcmahon@umbernetworks.com
To: Frantisek Borsik <frantisek.borsik@gmail.com>
Cc: Mikael Abrahamsson <swmike@swm.pp.se>,
	bloat <bloat@lists.bufferbloat.net>,
	Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>,
	Morten <morten@broerup.com>,
	Sebastian Moeller <sebastian.moeller@gmail.com>,
	Martycieslak <martycieslak@yahoo.com>,
	Koen DS <koen0607@gmail.com>, Carlos Jones <cjonesii@yahoo.com>,
	William Fisher <zzyzxr99@gmail.com>, Jiml <jiml@quicksmart.com>,
	Jim <jim@iniholdings.com>, Thomas <thomas@monjalon.net>,
	Robin Jarry <rjarry@redhat.com>,
	Tim Odriscoll <tim.odriscoll@intel.com>
Subject: [Bloat] Re: IETF proposal for provisioning ISP ratelimiter rate to RG
Date: Thu, 23 Jul 2026 13:24:48 -0700	[thread overview]
Message-ID: <53ceb60c8389a0abc4fb1157449e6fc4@umbernetworks.com> (raw)
In-Reply-To: <CAJUtOOgKL3oohWvwOfQJENODxonqvXD0m6+cOVFxx-p-D=Q7eQ@mail.gmail.com>

Herbert’s point about wireless indicating changes is exactly the problem 
we have been working on. Mikael’s draft covers the ISP informing the RG 
of the access rate; the wireless side is the complementary, and much 
faster-moving, half of that picture.

The goal of Fi-Wi is to make Wi-Fi and the WAN link a coupled, 
control-theoretic system, using the TXOP as the fundamental unit of 
wireless work. Scheduling, queue management, and rate adaptation can 
then be coordinated across both sides of the access path using real-time 
state rather than having each layer guess independently.

This simulation illustrates the challenge:

https://www.umbernetworks.com/mcs_fiwi.php

The values are simulated, not measured, so please treat it as a 
visualization rather than an experimental result.

I discussed the approach in this DPDK presentation:

https://youtu.be/kLdIXVPKT1I?si=03vZ3QB5zq2Whe69

Bob

> Lovely, thanks for sharing, Mikael!
> 
> To quote my LibreQoS colleague Herbert:
> 
> "THAT is a feature I've been asking for a couple of decades. I think 
> Dave
> [Täht] was the same way. We both also wanted some standardized 
> signalling
> so wireless could indicate changes, but that's a good start."
> 
> 
> 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 Thu, Jul 23, 2026 at 7:15 PM Mikael Abrahamsson via Bloat <
> bloat@lists.bufferbloat.net> wrote:
> 
>> 
>> https://datatracker.ietf.org/doc/draft-giese-dhcp-rate-signaling/
>> 
>> https://mailarchive.ietf.org/arch/browse/int-area/?gbt=1&page=1&qdr=m
>> 
>> This might be of interest to people on this list, as the age old trick 
>> of
>> manually creating a shaper with slightly below ISP configured speed, 
>> and
>> then running AQM in it to avoid the ISP FIFO now could automatically 
>> be
>> enabled by means of the ISP informing the RG of said rate.
>> 
>> Above is a link to mailing list discussion I started right after the
>> int-area presentation.
>> 
>> --
>> Mikael Abrahamsson    email: swmike@swm.pp.se
>> _______________________________________________
>> Bloat mailing list -- bloat@lists.bufferbloat.net
>> To unsubscribe send an email to bloat-leave@lists.bufferbloat.net
>> 
> _______________________________________________
> Bloat mailing list -- bloat@lists.bufferbloat.net
> To unsubscribe send an email to bloat-leave@lists.bufferbloat.net

  reply	other threads:[~2026-07-23 20:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-23 17:15 [Bloat] IETF proposal for provisioning ISP ratelimiter rate to RG Mikael Abrahamsson
2026-07-23 19:36 ` [Bloat] " Frantisek Borsik
2026-07-23 20:24   ` bob.mcmahon [this message]
2026-07-24  7:33 ` Sebastian Moeller

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=53ceb60c8389a0abc4fb1157449e6fc4@umbernetworks.com \
    --to=bob.mcmahon@umbernetworks.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=cjonesii@yahoo.com \
    --cc=frantisek.borsik@gmail.com \
    --cc=jim@iniholdings.com \
    --cc=jiml@quicksmart.com \
    --cc=koen0607@gmail.com \
    --cc=make-wifi-fast@lists.bufferbloat.net \
    --cc=martycieslak@yahoo.com \
    --cc=morten@broerup.com \
    --cc=rjarry@redhat.com \
    --cc=sebastian.moeller@gmail.com \
    --cc=swmike@swm.pp.se \
    --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