Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

QosIfy - dynamically remarking DSCPs via ebpf #113

Open
dtaht opened this issue Sep 21, 2022 · 1 comment
Open

QosIfy - dynamically remarking DSCPs via ebpf #113

dtaht opened this issue Sep 21, 2022 · 1 comment
Labels
Research Researchy things
Milestone

Comments

@dtaht
Copy link
Collaborator

dtaht commented Sep 21, 2022

Over here there is a clean module for recognizing identifiable traffic and applying diffserv markings to it, for cake. https://forum.openwrt.org/t/qosify-new-package-for-dscp-marking-cake/111789

I am no fan of dscp, and of the near religious fights over what each codepoint means. Also, many tests to date of linux's wifi code show how badly those interpretations "fit" into wifi's access classes (which govern access to the media, not flow behavior). As best as I can tell many older, and bigger ISPs use (or used to use it) to remark traffic and differentiate between voip, business, and residential traffic on a strict priority queue basis, and didn't (among other things) put CS1 into a background queue properly (which is why I actually am a proponent of the new LE codepoint in https://datatracker.ietf.org/doc/html/rfc8622 )

I as a user, would like very much to toss backups, and torrent, for example, into the background.

There are other, saner means of doing traffic engineering, and if I had any hope for DSCPs was that they would actually be preserved
e2e one day and more often. So far I primarily am observing that dscps are remarkably nowadays preserved e2e, and notably at least some cell phones are setting the right ones to land in the right tins in cake.

So, anyway cake does soft admission control for the classes it supports, rather than strict priority and is thus less dangerous to use.

So IMHO - on the whole FQ is, like 95% of a good solution, AQM 3%, ECN potentially another 1%, and the rest... magic. But I could be wrong, particularly when it comes to videoconferencing. I think strict priority queues exist, still, in a lot a gear, and so long as you are doing soft admission control a la cake, some marking might make sense, and taking stock of any improvements to how zoom might work, in particular has long been on my mind.

https://support.zoom.us/hc/en-us/articles/207368756-Using-QoS-DSCP-Marking

@dtaht dtaht added this to the v1.4 milestone Nov 13, 2022
@rchac rchac added the Research Researchy things label Feb 5, 2023
@dtaht dtaht modified the milestones: v1.4, v1.5 Mar 19, 2023
@dtaht
Copy link
Collaborator Author

dtaht commented Mar 19, 2023

I would like us to better observe actual DSCP mark usage in the wild, and whether or not they help.

@rchac rchac modified the milestones: v1.5 Beta, v1.6 May 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Research Researchy things
Projects
None yet
Development

No branches or pull requests

2 participants