Re: [Cake] [PATCH net-next] sched: sch_cake: Align QoS treatment to Windows and Zoom

[Sebastian Moeller <moeller0@gmx.de>]

Hi Dave,

I seem to recall that cake's DSCP to priority tin mapping always was intended to "do the right thing" by default and in that case that IMHO means do something useful with the few DSCPs that applications actually use in the wild (I might be somewhat wrong here in my impression, so Jonathan, please correct me if I am wrong). I think that is a solid guiding principle. 
If enough zoom sessions over the internet actually use these DSCPs seems fair to adjust cake's mapping to do something reasonable with them. I have no clue about the actual numbers but I can see how moving video from the tighter Voice tin to the wider Video tin makes sense


I still am a bit puzzled about zoom's choice of 56 for audio, but I guess I am just confused.


Question, since zoom does not use CS4, why move that around? To avoid CS4 having higher priority than CS5?

Regards
	Sebastian

P.S.: Has anybody tested whether this improves things enough in practice to be noticeable?


> On 22. Jan 2025, at 20:35, Dave Taht <dave.taht@gmail.com> wrote:
> 
> This patch just moves CS4 and CS5 to the video tin. I hope that´s ok?
> 
> On Fri, Jan 10, 2025 at 12:34 PM Sebastian Moeller <moeller0@gmx.de> wrote:
>> 
>> Hi Dave,
>> 
>>> On 10. Jan 2025, at 20:43, Dave Taht <dave.taht@gmail.com> wrote:
>>> 
>>> ok, I concede on NQB. Do we at least have agreement that CS5 belongs
>>> in the VI queue, not the VO queue, on diffserv4?
>> 
>> As I said, I have less issues with bumping things down than up (but I am also just voicing my opinion here, thanks for discussing, I am fine ending up in the "rough" here).
>> 
>> About Zoom (h++ps://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0066617):
>> "The default Zoom DSCP marking values are 56 for audio, 40 for video, and 40 for screen sharing. You can update audio and video values to allow a network administrator to adjust the priority for Zoom traffic on their network."
>> 
>> That 56 is CS7 for audio which I am pretty sure will not pass most of the internet (I believe the IETF recommends to drop CS7 on ingress from other ASs)... either they wanted to write 46 (EF) or they are just as confused as the WiFi WMM folks...
>> 
>> 
>> 
>> 
>> 
>>> 
>>> On Fri, Jan 10, 2025 at 9:43 AM Jonathan Morton <chromatix99@gmail.com> wrote:
>>>> 
>>>>> On 10 Jan, 2025, at 7:07 pm, Dave Taht via Cake <cake@lists.bufferbloat.net> wrote:
>>>>> 
>>>>> I do not think NQB belongs in Voice (which shares priority with
>>>>> netcontrol, etc). I also do not think it belongs in best effort as the
>>>>> intent is to get a quick response to a short flow. yes, FQ solves a
>>>>> lot of problems, but
>>>> 
>>>> As far as I'm concerned, FQ implements everything that NQB wants.  In a system implementing FQ, treating NQB traffic as best-effort is the Right Thing.
>>>> 
>>>> And I second the notion that slavishly copying wthe broken default behaviour of WiFi routers is the Wrong Thing.
>>>> 
>>>> - Jonathan Morton
>>>> 
>>> 
>>> 
>>> --
>>> Dave Täht CSO, LibreQos
>> 
> 
> 
> -- 
> Dave Täht CSO, LibreQos
> <0001-sch_cake-Align-QoS-treatment-to-Windows-and-Zoom.patch>