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

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

[Toke Høiland-Jørgensen]

From: Dave Taht <dave.taht@gmail.com>

Cake's diffserv4 mode attempted to follow the IETF webrtc
QoS marking standards, RFC8837.

It turns out Windows QoS can only use CS0, CS1, CS5, and CS7.

Zoom defaults to using CS5 for video and screen sharing traffic.

Bump CS4, CS5, and NQB to the video tin (2) in diffserv4 mode, for
more bandwidth and lower priority.

This also better aligns with how WiFi presently treats CS5 and NQB.

Signed-off-by: Dave Taht <dave.taht@gmail.com>
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
---
 net/sched/sch_cake.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c
index 48dd8c88903f..2a9288d4b873 100644
--- a/net/sched/sch_cake.c
+++ b/net/sched/sch_cake.c
@@ -328,8 +328,8 @@ static const u8 diffserv4[] = {
 	1, 0, 0, 0, 0, 0, 0, 0,
 	2, 0, 2, 0, 2, 0, 2, 0,
 	2, 0, 2, 0, 2, 0, 2, 0,
-	3, 0, 2, 0, 2, 0, 2, 0,
-	3, 0, 0, 0, 3, 0, 3, 0,
+	2, 0, 2, 0, 2, 0, 2, 0,
+	2, 0, 0, 0, 2, 0, 3, 0,
 	3, 0, 0, 0, 0, 0, 0, 0,
 	3, 0, 0, 0, 0, 0, 0, 0,
 };
-- 
2.47.1

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

[Sebastian Moeller]

Mmmh. off the Linux lists/folks for discussion:

can I propose to drop NQB down to BestEffort? The supposed requirements for NQB marking should make these flows thrive in a flow isolating scheduler like cake without any special treatment... moving it to Video or worse Voice really only invites abuse...



> On 10. Jan 2025, at 16:55, Toke Høiland-Jørgensen via Cake <cake@lists.bufferbloat.net> wrote:
> 
> From: Dave Taht <dave.taht@gmail.com>
> 
> Cake's diffserv4 mode attempted to follow the IETF webrtc
> QoS marking standards, RFC8837.
> 
> It turns out Windows QoS can only use CS0, CS1, CS5, and CS7.

Nah, applications apparently can only request a small set of DSCPs, but it is possible to make whole applications use a different DSCP:
example for making putty use EF

New-NetQosPolicy -Name "putty" -AppPathNameMatchCondition "putty.exe" -PolicyStore ActiveStore -NetworkProfile All -DSCPAction 46


> 
> Zoom defaults to using CS5 for video and screen sharing traffic.

Zoom defaults to using CS0 (my packet captures) unless an adminstrator enables DSCPs, which I assume will only/mostly happen for business accounts.


> Bump CS4, CS5, and NQB to the video tin (2) in diffserv4 mode, for
> more bandwidth and lower priority.

I do endorse that, but that change will affect all current users of cake as parts of their individual QoS hierarchies.

> 
> This also better aligns with how WiFi presently treats CS5 and NQB.

Two issues: it is not that default WiFi uses a sane system to begin with, and NQB IMHO should not be elevated in priority unless it is also policed well, something neither WiFi nor cake will do out of the box.


> 
> Signed-off-by: Dave Taht <dave.taht@gmail.com>
> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
> ---
> net/sched/sch_cake.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c
> index 48dd8c88903f..2a9288d4b873 100644
> --- a/net/sched/sch_cake.c
> +++ b/net/sched/sch_cake.c
> @@ -328,8 +328,8 @@ static const u8 diffserv4[] = {
> 1, 0, 0, 0, 0, 0, 0, 0,
> 2, 0, 2, 0, 2, 0, 2, 0,
> 2, 0, 2, 0, 2, 0, 2, 0,
> - 3, 0, 2, 0, 2, 0, 2, 0,
> - 3, 0, 0, 0, 3, 0, 3, 0,
> + 2, 0, 2, 0, 2, 0, 2, 0,
> + 2, 0, 0, 0, 2, 0, 3, 0,
> 3, 0, 0, 0, 0, 0, 0, 0,
> 3, 0, 0, 0, 0, 0, 0, 0,
> };
> -- 
> 2.47.1
> 
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

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

[Dave Taht]

actually in re-reading that, I think it leaves nqb in 0 (44, not 45,
is now VI), which wasn't my intent.

More below...

On Fri, Jan 10, 2025 at 8:24 AM Sebastian Moeller <moeller0@gmx.de> wrote:
>
> Mmmh. off the Linux lists/folks for discussion:
>
> can I propose to drop NQB down to BestEffort? The supposed requirements for NQB marking should make these flows thrive in a flow isolating scheduler like cake without any special treatment... moving it to Video or worse Voice really only invites abuse...

I would prefer consistent behavior.

>
>
>
> > On 10. Jan 2025, at 16:55, Toke Høiland-Jørgensen via Cake <cake@lists.bufferbloat.net> wrote:
> >
> > From: Dave Taht <dave.taht@gmail.com>
> >
> > Cake's diffserv4 mode attempted to follow the IETF webrtc
> > QoS marking standards, RFC8837.
> >
> > It turns out Windows QoS can only use CS0, CS1, CS5, and CS7.
>
> Nah, applications apparently can only request a small set of DSCPs, but it is possible to make whole applications use a different DSCP:
> example for making putty use EF
>
> New-NetQosPolicy -Name "putty" -AppPathNameMatchCondition "putty.exe" -PolicyStore ActiveStore -NetworkProfile All -DSCPAction 46

Within an App...

>
>
> >
> > Zoom defaults to using CS5 for video and screen sharing traffic.
>
> Zoom defaults to using CS0 (my packet captures) unless an adminstrator enables DSCPs, which I assume will only/mostly happen for business accounts.

I have seen it enabled. I have also multiple reports of "stuttering",
which I am hoping this resolves.

>
> > Bump CS4, CS5, and NQB to the video tin (2) in diffserv4 mode, for
> > more bandwidth and lower priority.
>
> I do endorse that, but that change will affect all current users of cake as parts of their individual QoS hierarchies.

I think windows users are not as  clued.
> >
> > This also better aligns with how WiFi presently treats CS5 and NQB.
>
> Two issues: it is not that default WiFi uses a sane system to begin with, and NQB IMHO should not be elevated in priority unless it is also policed well, something neither WiFi nor cake will do out of the box.
>
>
> >
> > Signed-off-by: Dave Taht <dave.taht@gmail.com>
> > Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
> > ---
> > net/sched/sch_cake.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c
> > index 48dd8c88903f..2a9288d4b873 100644
> > --- a/net/sched/sch_cake.c
> > +++ b/net/sched/sch_cake.c
> > @@ -328,8 +328,8 @@ static const u8 diffserv4[] = {
> > 1, 0, 0, 0, 0, 0, 0, 0,
> > 2, 0, 2, 0, 2, 0, 2, 0,
> > 2, 0, 2, 0, 2, 0, 2, 0,
> > - 3, 0, 2, 0, 2, 0, 2, 0,
> > - 3, 0, 0, 0, 3, 0, 3, 0,
> > + 2, 0, 2, 0, 2, 0, 2, 0,
> > + 2, 0, 0, 0, 2, 0, 3, 0,
> > 3, 0, 0, 0, 0, 0, 0, 0,
> > 3, 0, 0, 0, 0, 0, 0, 0,
> > };
> > --
> > 2.47.1
> >
> > _______________________________________________
> > Cake mailing list
> > Cake@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cake
>


-- 
Dave Täht CSO, LibreQos

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

[Sebastian Moeller]

On 10 January 2025 17:34:45 CET, Dave Taht <dave.taht@gmail.com> wrote:
>actually in re-reading that, I think it leaves nqb in 0 (44, not 45,
>is now VI), which wasn't my intent.
>
>More below...
>
>On Fri, Jan 10, 2025 at 8:24 AM Sebastian Moeller <moeller0@gmx.de> wrote:
>>
>> Mmmh. off the Linux lists/folks for discussion:
>>
>> can I propose to drop NQB down to BestEffort? The supposed requirements for NQB marking should make these flows thrive in a flow isolating scheduler like cake without any special treatment... moving it to Video or worse Voice really only invites abuse...
>
>I would prefer consistent behavior.

Without proper policing, NQB in Voice, with all/most other traffic in BestEffort a single NQB flow can easily hog up to 50% (I believe this is the cake default) of capacity... 
first rule of priority schedulers think twice before exposing a priority scheduler without admission control to the wider internet...

>
>>
>>
>>
>> > On 10. Jan 2025, at 16:55, Toke Høiland-Jørgensen via Cake <cake@lists.bufferbloat.net> wrote:
>> >
>> > From: Dave Taht <dave.taht@gmail.com>
>> >
>> > Cake's diffserv4 mode attempted to follow the IETF webrtc
>> > QoS marking standards, RFC8837.
>> >
>> > It turns out Windows QoS can only use CS0, CS1, CS5, and CS7.
>>
>> Nah, applications apparently can only request a small set of DSCPs, but it is possible to make whole applications use a different DSCP:
>> example for making putty use EF
>>
>> New-NetQosPolicy -Name "putty" -AppPathNameMatchCondition "putty.exe" -PolicyStore ActiveStore -NetworkProfile All -DSCPAction 46
>
>Within an App...

Yepp, that solves zoom's issue, as I am willing to bet default all CS0 zoom does not have fluidity issues due to congesting itself...

>
>>
>>
>> >
>> > Zoom defaults to using CS5 for video and screen sharing traffic.
>>
>> Zoom defaults to using CS0 (my packet captures) unless an adminstrator enables DSCPs, which I assume will only/mostly happen for business accounts.
>
>I have seen it enabled. 

Sure, on business accounts that do come with an administrator access to the businesses zoom account... typical home users are CS0 all the way, all the time.

> I have also multiple reports of "stuttering",
>which I am hoping this resolves.
>
>>
>> > Bump CS4, CS5, and NQB to the video tin (2) in diffserv4 mode, for
>> > more bandwidth and lower priority.
>>
>> I do endorse that, but that change will affect all current users of cake as parts of their individual QoS hierarchies.
>
>I think windows users are not as  clued.

They are also not that likely to use cake in the first place... so for the convenience on users we do not have we risk annoying experienced users. I am not saying this should stop us but we should consider that, after all this can not easily be overridden via the commandline.

>> >
>> > This also better aligns with how WiFi presently treats CS5 and NQB.
>>
>> Two issues: it is not that default WiFi uses a sane system to begin with, and NQB IMHO should not be elevated in priority unless it is also policed well, something neither WiFi nor cake will do out of the box.
>>
>>
>> >
>> > Signed-off-by: Dave Taht <dave.taht@gmail.com>
>> > Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
>> > ---
>> > net/sched/sch_cake.c | 4 ++--
>> > 1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c
>> > index 48dd8c88903f..2a9288d4b873 100644
>> > --- a/net/sched/sch_cake.c
>> > +++ b/net/sched/sch_cake.c
>> > @@ -328,8 +328,8 @@ static const u8 diffserv4[] = {
>> > 1, 0, 0, 0, 0, 0, 0, 0,
>> > 2, 0, 2, 0, 2, 0, 2, 0,
>> > 2, 0, 2, 0, 2, 0, 2, 0,
>> > - 3, 0, 2, 0, 2, 0, 2, 0,
>> > - 3, 0, 0, 0, 3, 0, 3, 0,
>> > + 2, 0, 2, 0, 2, 0, 2, 0,
>> > + 2, 0, 0, 0, 2, 0, 3, 0,
>> > 3, 0, 0, 0, 0, 0, 0, 0,
>> > 3, 0, 0, 0, 0, 0, 0, 0,
>> > };
>> > --
>> > 2.47.1
>> >
>> > _______________________________________________
>> > Cake mailing list
>> > Cake@lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/cake
>>
>
>

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

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

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 4818 bytes --]

On Fri, Jan 10, 2025 at 9:02 AM Sebastian Moeller <moeller0@gmx.de> wrote:
>
>
>
> On 10 January 2025 17:34:45 CET, Dave Taht <dave.taht@gmail.com> wrote:
> >actually in re-reading that, I think it leaves nqb in 0 (44, not 45,
> >is now VI), which wasn't my intent.
> >
> >More below...
> >
> >On Fri, Jan 10, 2025 at 8:24 AM Sebastian Moeller <moeller0@gmx.de> wrote:
> >>
> >> Mmmh. off the Linux lists/folks for discussion:
> >>
> >> can I propose to drop NQB down to BestEffort? The supposed requirements for NQB marking should make these flows thrive in a flow isolating scheduler like cake without any special treatment... moving it to Video or worse Voice really only invites abuse...
> >
> >I would prefer consistent behavior.
>
> Without proper policing, NQB in Voice, with all/most other traffic in BestEffort a single NQB flow can easily hog up to 50% (I believe this is the cake default) of capacity...
> first rule of priority schedulers think twice before exposing a priority scheduler without admission control to the wider internet...

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

At some point you have to trust the intent..

>
> >
> >>
> >>
> >>
> >> > On 10. Jan 2025, at 16:55, Toke Høiland-Jørgensen via Cake <cake@lists.bufferbloat.net> wrote:
> >> >
> >> > From: Dave Taht <dave.taht@gmail.com>
> >> >
> >> > Cake's diffserv4 mode attempted to follow the IETF webrtc
> >> > QoS marking standards, RFC8837.
> >> >
> >> > It turns out Windows QoS can only use CS0, CS1, CS5, and CS7.
> >>
> >> Nah, applications apparently can only request a small set of DSCPs, but it is possible to make whole applications use a different DSCP:
> >> example for making putty use EF
> >>
> >> New-NetQosPolicy -Name "putty" -AppPathNameMatchCondition "putty.exe" -PolicyStore ActiveStore -NetworkProfile All -DSCPAction 46
> >
> >Within an App...
>
> Yepp, that solves zoom's issue, as I am willing to bet default all CS0 zoom does not have fluidity issues due to congesting itself...
>
> >
> >>
> >>
> >> >
> >> > Zoom defaults to using CS5 for video and screen sharing traffic.
> >>
> >> Zoom defaults to using CS0 (my packet captures) unless an adminstrator enables DSCPs, which I assume will only/mostly happen for business accounts.
> >
> >I have seen it enabled.
>
> Sure, on business accounts that do come with an administrator access to the businesses zoom account... typical home users are CS0 all the way, all the time.
>
> > I have also multiple reports of "stuttering",
> >which I am hoping this resolves.
> >
> >>
> >> > Bump CS4, CS5, and NQB to the video tin (2) in diffserv4 mode, for
> >> > more bandwidth and lower priority.
> >>
> >> I do endorse that, but that change will affect all current users of cake as parts of their individual QoS hierarchies.
> >
> >I think windows users are not as  clued.
>
> They are also not that likely to use cake in the first place... so for the convenience on users we do not have we risk annoying experienced users. I am not saying this should stop us but we should consider that, after all this can not easily be overridden via the commandline.
>
> >> >
> >> > This also better aligns with how WiFi presently treats CS5 and NQB.
> >>
> >> Two issues: it is not that default WiFi uses a sane system to begin with, and NQB IMHO should not be elevated in priority unless it is also policed well, something neither WiFi nor cake will do out of the box.
> >>
> >>
> >> >
> >> > Signed-off-by: Dave Taht <dave.taht@gmail.com>
> >> > Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
> >> > ---
> >> > net/sched/sch_cake.c | 4 ++--
> >> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c
> >> > index 48dd8c88903f..2a9288d4b873 100644
> >> > --- a/net/sched/sch_cake.c
> >> > +++ b/net/sched/sch_cake.c
> >> > @@ -328,8 +328,8 @@ static const u8 diffserv4[] = {
> >> > 1, 0, 0, 0, 0, 0, 0, 0,
> >> > 2, 0, 2, 0, 2, 0, 2, 0,
> >> > 2, 0, 2, 0, 2, 0, 2, 0,
> >> > - 3, 0, 2, 0, 2, 0, 2, 0,
> >> > - 3, 0, 0, 0, 3, 0, 3, 0,
> >> > + 2, 0, 2, 0, 2, 0, 2, 0,
> >> > + 2, 0, 0, 0, 2, 0, 3, 0,
> >> > 3, 0, 0, 0, 0, 0, 0, 0,
> >> > 3, 0, 0, 0, 0, 0, 0, 0,
> >> > };
> >> > --
> >> > 2.47.1
> >> >
> >> > _______________________________________________
> >> > Cake mailing list
> >> > Cake@lists.bufferbloat.net
> >> > https://lists.bufferbloat.net/listinfo/cake
> >>
> >
> >
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.



-- 
Dave Täht CSO, LibreQos

[-- Attachment #2: 0001-sch_cake-Align-QoS-treatment-to-Windows-and-Zoom.patch --]
[-- Type: application/octet-stream, Size: 1368 bytes --]

From 23051fde327384a3701a58014f63da98035d531a Mon Sep 17 00:00:00 2001
From: Dave Taht <dave.taht@gmail.com>
Date: Thu, 9 Jan 2025 18:23:01 +0000
Subject: [PATCH] sch_cake: Align QoS treatment to Windows and Zoom

Cake's diffserv4 mode attempted to follow the IETF webrtc
QoS marking standards in RFC8837.

It turns out Windows Application level QoS can only select
CS0, CS1, CS5, and CS7. 

You can actually set anything at the shell via (for example):

New-NetQosPolicy -Name "putty" -AppPathNameMatchCondition "putty.exe"
-PolicyStore ActiveStore -NetworkProfile All -DSCPAction 46

But:

Zoom defaults to using CS5 for video and screen sharing traffic.

Bump CS4, CS5, and NQB to the video tin (2) in diffserv4 mode, for
more bandwidth and less priority.

This also better aligns with how WiFi presently treats CS5 and NQB.


---
 net/sched/sch_cake.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c
index deb0925f536d..52c6faf2c273 100644
--- a/net/sched/sch_cake.c
+++ b/net/sched/sch_cake.c
@@ -328,8 +328,8 @@ static const u8 diffserv4[] = {
 	1, 0, 0, 0, 0, 0, 0, 0,
 	2, 0, 2, 0, 2, 0, 2, 0,
 	2, 0, 2, 0, 2, 0, 2, 0,
-	3, 0, 2, 0, 2, 0, 2, 0,
-	3, 0, 0, 0, 3, 0, 3, 0,
+	2, 0, 2, 0, 2, 0, 2, 0,
+	2, 0, 0, 0, 2, 2, 3, 0,
 	3, 0, 0, 0, 0, 0, 0, 0,
 	3, 0, 0, 0, 0, 0, 0, 0,
 };
-- 
2.43.0

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

[Sebastian Moeller]

On 10 January 2025 18:07:46 CET, Dave Taht <dave.taht@gmail.com> wrote:
>On Fri, Jan 10, 2025 at 9:02 AM Sebastian Moeller <moeller0@gmx.de> wrote:
>>
>>
>>
>> On 10 January 2025 17:34:45 CET, Dave Taht <dave.taht@gmail.com> wrote:
>> >actually in re-reading that, I think it leaves nqb in 0 (44, not 45,
>> >is now VI), which wasn't my intent.
>> >
>> >More below...
>> >
>> >On Fri, Jan 10, 2025 at 8:24 AM Sebastian Moeller <moeller0@gmx.de> wrote:
>> >>
>> >> Mmmh. off the Linux lists/folks for discussion:
>> >>
>> >> can I propose to drop NQB down to BestEffort? The supposed requirements for NQB marking should make these flows thrive in a flow isolating scheduler like cake without any special treatment... moving it to Video or worse Voice really only invites abuse...
>> >
>> >I would prefer consistent behavior.
>>
>> Without proper policing, NQB in Voice, with all/most other traffic in BestEffort a single NQB flow can easily hog up to 50% (I believe this is the cake default) of capacity...
>> first rule of priority schedulers think twice before exposing a priority scheduler without admission control to the wider internet...
>
>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
>
>At some point you have to trust the intent..

I do not trust NQB, I consider that to be evidence of how far the IETF has lowered its standards to ratify that junk.
Another example of engineering by wishful thinking and motivated reasoning.

>
>>
>> >
>> >>
>> >>
>> >>
>> >> > On 10. Jan 2025, at 16:55, Toke Høiland-Jørgensen via Cake <cake@lists.bufferbloat.net> wrote:
>> >> >
>> >> > From: Dave Taht <dave.taht@gmail.com>
>> >> >
>> >> > Cake's diffserv4 mode attempted to follow the IETF webrtc
>> >> > QoS marking standards, RFC8837.
>> >> >
>> >> > It turns out Windows QoS can only use CS0, CS1, CS5, and CS7.
>> >>
>> >> Nah, applications apparently can only request a small set of DSCPs, but it is possible to make whole applications use a different DSCP:
>> >> example for making putty use EF
>> >>
>> >> New-NetQosPolicy -Name "putty" -AppPathNameMatchCondition "putty.exe" -PolicyStore ActiveStore -NetworkProfile All -DSCPAction 46
>> >
>> >Within an App...
>>
>> Yepp, that solves zoom's issue, as I am willing to bet default all CS0 zoom does not have fluidity issues due to congesting itself...
>>
>> >
>> >>
>> >>
>> >> >
>> >> > Zoom defaults to using CS5 for video and screen sharing traffic.
>> >>
>> >> Zoom defaults to using CS0 (my packet captures) unless an adminstrator enables DSCPs, which I assume will only/mostly happen for business accounts.
>> >
>> >I have seen it enabled.
>>
>> Sure, on business accounts that do come with an administrator access to the businesses zoom account... typical home users are CS0 all the way, all the time.
>>
>> > I have also multiple reports of "stuttering",
>> >which I am hoping this resolves.
>> >
>> >>
>> >> > Bump CS4, CS5, and NQB to the video tin (2) in diffserv4 mode, for
>> >> > more bandwidth and lower priority.
>> >>
>> >> I do endorse that, but that change will affect all current users of cake as parts of their individual QoS hierarchies.
>> >
>> >I think windows users are not as  clued.
>>
>> They are also not that likely to use cake in the first place... so for the convenience on users we do not have we risk annoying experienced users. I am not saying this should stop us but we should consider that, after all this can not easily be overridden via the commandline.
>>
>> >> >
>> >> > This also better aligns with how WiFi presently treats CS5 and NQB.
>> >>
>> >> Two issues: it is not that default WiFi uses a sane system to begin with, and NQB IMHO should not be elevated in priority unless it is also policed well, something neither WiFi nor cake will do out of the box.
>> >>
>> >>
>> >> >
>> >> > Signed-off-by: Dave Taht <dave.taht@gmail.com>
>> >> > Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
>> >> > ---
>> >> > net/sched/sch_cake.c | 4 ++--
>> >> > 1 file changed, 2 insertions(+), 2 deletions(-)
>> >> >
>> >> > diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c
>> >> > index 48dd8c88903f..2a9288d4b873 100644
>> >> > --- a/net/sched/sch_cake.c
>> >> > +++ b/net/sched/sch_cake.c
>> >> > @@ -328,8 +328,8 @@ static const u8 diffserv4[] = {
>> >> > 1, 0, 0, 0, 0, 0, 0, 0,
>> >> > 2, 0, 2, 0, 2, 0, 2, 0,
>> >> > 2, 0, 2, 0, 2, 0, 2, 0,
>> >> > - 3, 0, 2, 0, 2, 0, 2, 0,
>> >> > - 3, 0, 0, 0, 3, 0, 3, 0,
>> >> > + 2, 0, 2, 0, 2, 0, 2, 0,
>> >> > + 2, 0, 0, 0, 2, 0, 3, 0,
>> >> > 3, 0, 0, 0, 0, 0, 0, 0,
>> >> > 3, 0, 0, 0, 0, 0, 0, 0,
>> >> > };
>> >> > --
>> >> > 2.47.1
>> >> >
>> >> > _______________________________________________
>> >> > Cake mailing list
>> >> > Cake@lists.bufferbloat.net
>> >> > https://lists.bufferbloat.net/listinfo/cake
>> >>
>> >
>> >
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
>
>

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

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

[Jonathan Morton]

> 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

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

[Dave Taht]

ok, I concede on NQB. Do we at least have agreement that CS5 belongs
in the VI queue, not the VO queue, on diffserv4?

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

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

[Sebastian Moeller]

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

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

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 2003 bytes --]

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

[-- Attachment #2: 0001-sch_cake-Align-QoS-treatment-to-Windows-and-Zoom.patch --]
[-- Type: application/octet-stream, Size: 1123 bytes --]

From 23051fde327384a3701a58014f63da98035d531a Mon Sep 17 00:00:00 2001
From: Dave Taht <dave.taht@gmail.com>
Date: Thu, 9 Jan 2025 18:23:01 +0000
Subject: [PATCH] sch_cake: Align QoS treatment to Windows and Zoom

Cake's diffserv4 mode attempted to follow the IETF webrtc
QoS marking standards in RFC8837. 

It turns Windows QoS can only use CS0, CS1, CS5, and CS7.

Zoom defaults to using CS5 for video ahd screen sharing traffic.

Bump down to the video tin (2) CS4, and CS5 for
more bandwidth and less priority.

This also better aligns with how WiFi presently
treats CS4 and CS5.

---
 net/sched/sch_cake.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c
index deb0925f536d..52c6faf2c273 100644
--- a/net/sched/sch_cake.c
+++ b/net/sched/sch_cake.c
@@ -328,8 +328,8 @@ static const u8 diffserv4[] = {
 	1, 0, 0, 0, 0, 0, 0, 0,
 	2, 0, 2, 0, 2, 0, 2, 0,
 	2, 0, 2, 0, 2, 0, 2, 0,
-	3, 0, 2, 0, 2, 0, 2, 0,
-	3, 0, 0, 0, 3, 0, 3, 0,
+	2, 0, 2, 0, 2, 0, 2, 0,
+	2, 0, 0, 0, 3, 0, 3, 0,
 	3, 0, 0, 0, 0, 0, 0, 0,
 	3, 0, 0, 0, 0, 0, 0, 0,
 };
-- 
2.43.0

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

[Sebastian Moeller]

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>

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

[Toke Høiland-Jørgensen]

Toke Høiland-Jørgensen <toke@redhat.com> writes:

> From: Dave Taht <dave.taht@gmail.com>
>
> Cake's diffserv4 mode attempted to follow the IETF webrtc
> QoS marking standards, RFC8837.
>
> It turns out Windows QoS can only use CS0, CS1, CS5, and CS7.
>
> Zoom defaults to using CS5 for video and screen sharing traffic.
>
> Bump CS4, CS5, and NQB to the video tin (2) in diffserv4 mode, for
> more bandwidth and lower priority.
>
> This also better aligns with how WiFi presently treats CS5 and NQB.
>
> Signed-off-by: Dave Taht <dave.taht@gmail.com>
> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>

Alright, there was some discussion on the cake list re: this. Please
drop.

pw-bot: changes-requested