From: Sebastian Moeller <moeller0@gmx.de>
To: Dave Taht <dave.taht@gmail.com>
Cc: "Toke Høiland-Jørgensen" <toke@redhat.com>,
"Toke Høiland-Jørgensen" <toke@toke.dk>,
cake@lists.bufferbloat.net
Subject: Re: [Cake] [PATCH net-next] sched: sch_cake: Align QoS treatment to Windows and Zoom
Date: Fri, 10 Jan 2025 18:17:02 +0100 [thread overview]
Message-ID: <045726EE-7219-4E62-B9B3-47A75456D6BE@gmx.de> (raw)
In-Reply-To: <CAA93jw4mj2RdtqdDT3ug5j8EZSsYujC1V_SjQEcjmCVCUZU+jw@mail.gmail.com>
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.
next prev parent reply other threads:[~2025-01-10 17:17 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 [this message]
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
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=045726EE-7219-4E62-B9B3-47A75456D6BE@gmx.de \
--to=moeller0@gmx.de \
--cc=cake@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
--cc=toke@redhat.com \
--cc=toke@toke.dk \
/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