Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: "Jonathan Morton" <chromatix99@gmail.com>,
	cake@lists.bufferbloat.net,
	"Toke Høiland-Jørgensen" <toke@redhat.com>
Subject: Re: [Cake] [PATCH net-next] sched: sch_cake: Align QoS treatment to Windows and Zoom
Date: Wed, 22 Jan 2025 11:35:57 -0800	[thread overview]
Message-ID: <CAA93jw5oyChfNmX1bekA_Vwwv8YMqTtCH8ixufrdLh88PcZ5Tw@mail.gmail.com> (raw)
In-Reply-To: <F4B37725-18F6-45DB-8BD1-02849E146108@gmx.de>

[-- 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


  reply	other threads:[~2025-01-22 19:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-10 15:55 Toke Høiland-Jørgensen
2025-01-10 16:24 ` Sebastian Moeller
2025-01-10 16:34   ` Dave Taht
2025-01-10 17:02     ` Sebastian Moeller
2025-01-10 17:07       ` Dave Taht
2025-01-10 17:17         ` Sebastian Moeller
2025-01-10 17:43         ` Jonathan Morton
2025-01-10 19:43           ` Dave Taht
2025-01-10 20:34             ` Sebastian Moeller
2025-01-22 19:35               ` Dave Taht [this message]
2025-01-22 21:18                 ` Sebastian Moeller
2025-01-10 19:06 ` Toke Høiland-Jørgensen

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/cake.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA93jw5oyChfNmX1bekA_Vwwv8YMqTtCH8ixufrdLh88PcZ5Tw@mail.gmail.com \
    --to=dave.taht@gmail.com \
    --cc=cake@lists.bufferbloat.net \
    --cc=chromatix99@gmail.com \
    --cc=moeller0@gmx.de \
    --cc=toke@redhat.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