[Bloat] IETF proposal for provisioning ISP ratelimiter rate to RG

[Bloat] IETF proposal for provisioning ISP ratelimiter rate to RG

[Mikael Abrahamsson]

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] Re: IETF proposal for provisioning ISP ratelimiter rate to RG

[Frantisek Borsik]

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] Re: IETF proposal for provisioning ISP ratelimiter rate to RG

[bob.mcmahon]

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

[Bloat] Re: IETF proposal for provisioning ISP ratelimiter rate to RG

[Sebastian Moeller]

Great find! Thanks a lot.


Interesting.


I note that AVM/Fritz! has been winging something similar for PPPoE for some years already:
https://web.archive.org/web/20260414221556/https://fritz.support/resources/PPP-Controlled_Settings_for_FRITZOS_v1.3.pdf

so far and as I know only Deutsche Telekom and 1&1 actually use that, and since this is not a proper standard, both use slightly different encodings...

I also note that AVM's solution falls short of my wish list:

1) gross policer/shaper rate on the ISP side for both down- and up-direction
2) applicable per packet overhead for both down- and up-direction
3) information about specific fancy encapsulations that need to be taken into account (ATM/AAL5, I am looking at you)
4) MTU to ISP, and MTU to internet. Now this is essentially discoverable (at least the MTU to internet) so optional

I will have a look what the ID actually contains...

Regards



> On Jul 23, 2026, at 19:15, 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