[Starlink] Re: Wi-Fi Alliance’s QoS Management Specification Release 2 (R2) what's this new standard about?

[Sebastian Moeller <moeller0@gmx.de>]

On December 13, 2025 12:02:12 PM GMT+01:00, Frantisek Borsik via Starlink <starlink@lists.bufferbloat.net> wrote:
>Sadly, no real deal; FQ-CoDel with BQL and CAKE, from what I see.

This is, as expected. pretty weak. It is a way for stations to request an AP to put specific downstream flows in specific user priorities and thereby into different Access Classes, which are WiFi's stochastic priority tiers.

The base idea is not terrible, and as so often the Linux bufferbloat/qos community is doing something similar already (taking potentially validated DSCP markings from upstream packets and copy them unto related downstream packets, to allow priority treatment of downstream packets in accordance with local priority rules).
But it is also not earth shattering and massively relies on that local priority tiers make sense. And there this proposal falls quite short, the 4 EDCA classes with their default parameters are not a well balanced and selected set, but rather a quickly thrown together demo how this mechanism could be used that nobody so far touched again. I have been told, they needed to put something into the standard and so they did, nobody said it needed to be optimal, and it was assumed local networks would do their own local optimisations#.

I am with Koen De Schepper on this (as far as I understand his proposal, I might be wrong in my understanding, so do not assume flaws in Koen's proposal) replace the four ACs with a single AC that shares well with itself (and with the existing default ACs, as the world is going to ude thecdefaults for a long time) and put all the additional logic into the stations' and APs' queue management. The discussion how to manage those queues best is IMHO not settled yet.


#) Which was not a well thought out plan, at least not for the world we live in now with massive amounts of overlapping WiFi networks that share airtime, if I configure all my traffic to use AC_VO I will steal airtime from my neighbours' using the same channel. Koen's proposed better single AC parameters share airtime reasonably equitably with the existing default EDCA parameter sets andchence seem safe to deploy.


>
>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 Fri, 12 Dec 2025 at 3:12 PM, Inemesit Affia via Starlink <
>starlink@lists.bufferbloat.net> wrote:
>
>> From
>>
>> https://www.rcrwireless.com/20251205/network-infrastructure/wi-fi-qos
>>
>> Dec 11, 2025 2:40:31 AM Inemesit Affia <inemesitaffia@gmail.com>:
>>
>> > An image from AWS Invent.
>> >
>> > They expect sub 46-50 ms at launch.
>> >
>> > None of us live in a POP/NAP but I've seen Speedtest pings on Starlink
>> sub 17ms so..
>> >
>> > I wonder what OneWeb is capable of. I'm seeing 45ms as best case for
>> them in the field.
>> >
>> > Dec 9, 2025 12:33:51 AM David Lang <david@lang.hm>:
>> >
>> >> Michael Kan wrote:
>> >>
>> >>> latency for Amazon Leo? https://www.youtube.com/watch?v=nZCx612z930
>> >>
>> >> Until they have the system operational, be very leery about bandwidth
>> and latency claims.
>> >>
>> >> Remember that Starlink had to do-bloat things to make their
>> user-experienced latency line up with their early lab tests.
>> >>
>> >> David Lang
>> _______________________________________________
>> Starlink mailing list -- starlink@lists.bufferbloat.net
>> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>>
>_______________________________________________
>Starlink mailing list -- starlink@lists.bufferbloat.net
>To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.