If I had anyhing 50+ mbit I wouldn't bother with these things and would probably just use piece of cake or default layer cake. But in my case prioritizing is the only way to make sure the other things I want are working fine.
1 Like
Well, no actually... your problem is that you want to throttle battle.net dynamically... and use the same computer running the downloads to do other stuff at the same time. You could:
a) just configure battle.net downloads to not exceed a certain max speed, but that would not be dynamic and mean all such downloads would take longer independent of other use cases.
b) just stream video/twitch from a different machine, then cake's internal-IP-fairness mode would give the battle.net machine and the video machine equal shares of capacity independent of how many parallel flows blizzards download tool will use.
c) try to find heuristics that allow you to reliably push battle.net downloads into the bulk class...
d) find heuristics that push your video streaming into the video class
e) simply change "what you want" to be close to what you can achieve more easily (that does not solve a technical issue, but might give you more peace of mind).
3 Likes
Not really, some of us have 1 G/bit and still require this, as we live on WiFi and is kind of important to mark packets properly in your wireless network, in special when it's shared for work, stream and kid things.
3 Likes
Recently I've changed some of my own custom classifier rules to be based on packets per second. I have gigabit but as @amteza says wifi becomes the bottleneck. If a UDP or TCP stream is using less than 250 pps I up prioritize it, and if it uses more than 4000pps I down prioritize it. For my use case this seems to work exceedingly well and is simple. I also do a few classifications outside this, such as traffic to/from my NAS and certain traffic from my proxy based on domain name, but the packet rate heuristic is quite good. In particular it results in up prioritization of all voip traffic, and all game traffic (including Minecraft which uses variable rate TCP streams). For video confs I have identified ports used by the major platforms.
2 Likes
Examples besides what you originally shared on Github?
Yeah, i've been playing with my own stuff on my network... here's what I'm running at the moment:
# set up some sets for later doing packet rate limit matches
set ip_sparse {
typeof ip saddr . ip daddr . udp sport . udp dport
size 65535
flags timeout,dynamic
}
set ip6_sparse {
typeof ip6 saddr . ip6 daddr . udp sport . udp dport
size 65535
flags timeout,dynamic
}
set ip_bulk {
typeof ip saddr . ip daddr . tcp sport . tcp dport
size 65535
flags timeout,dynamic
}
set ip6_bulk {
typeof ip6 saddr . ip6 daddr . tcp sport . tcp dport
size 65535
flags timeout,dynamic
}
...
...
ip protocol udp ip saddr != 127.0.0.0/8 add @ip_sparse { ip saddr . ip daddr . udp sport . udp dport timeout 60s limit rate 250/second } ip dscp set cs5 counter
ip6 nexthdr udp ip6 saddr != ::1 add @ip6_sparse { ip6 saddr . ip6 daddr . udp sport . udp dport timeout 60s limit rate 250/second } ip6 dscp set cs5 counter
ip protocol tcp ip saddr != 127.0.0.0/8 ct bytes ge 375000000 add @ip_bulk { ip saddr . ip daddr . tcp sport . tcp dport timeout 60s limit rate over 4000/second } ip dscp set cs2 counter
ip6 nexthdr tcp ip6 saddr != ::1 ct bytes ge 375000000 add @ip6_bulk { ip6 saddr . ip6 daddr . tcp sport . tcp dport timeout 60s limit rate over 4000/second } ip6 dscp set cs2 counter
...
meta priority set 1:40 ## default
meta priority set ip dscp map { ef : "1:10" , cs6 : "1:10", cs5 : "1:20" ,
cs4 : "1:30",
af41 : "1:30",
af42 : "1:30",
af43 : "1:30",
cs2 : "1:50",
cs1 : "1:60"
}
meta priority set ip6 dscp map { ef : "1:10" , cs6 : "1:10", cs5 : "1:20" ,
cs4 : "1:30",
af41 : "1:30",
af42 : "1:30",
af43 : "1:30",
cs2 : "1:50",
cs1 : "1:60"
}
You'd want to tune some of that stuff for your own speeds etc, and in my case I use a different set of mappings than Cake does by default, because I'm still stubbornly using my HFSC based QoS system.
In my network "normal" priority is CS3, CS2 is downrated, CS1 is very downrated, CS4 is uprated, CS5 is real-time and CS6 is even higher priority realtime (with a lower speed limit). Basically CS6 is for VOIP and CS5 is for gaming, CS4 is for things like preventing stuttering on video streaming or making sure DNS lookups don't get stalled or etc.
If you look at it, 250 pps is about 3Mbps at most. So in this case the streams I'm up-prioritizing are each less than 3Mbps, but there could be several of them, so I could be up-prioritizing 30-40 Mbps if there were enough streams doing that sort of thing. That's not a big deal for a person with a gigabit connection, but could be a big issue for someone with a 30Mbps connection.
Still, I've found that it gives me pretty good situation. My wife is on a video call right now and I just ran a speed test, and she had no complaints. Probably the main reason for that is that the speed-test itself will be doing more than 4000 pps (about 50Mbps) so they're going to have to wait for even non-prioritized traffic.
One thing I'll say is that the bufferbloat tests like waveform's don't measure what you want to measure if you start fiddling with stuff like this. They're going to down-prioritize the streams in use, and potentially it'll appear to be more buffery, when in fact say a game with a low-rate UDP stream would speed on through.
1 Like
Aha! That make sense, I was wondering about this after seeing your rules. My approach is a bit different but it works very well too. I know one of your limitations is your WiFi APs are not supported by OpenWrt, correct?
In my case the big difference is made by this little trick —unorthodox, I know:
option iw_qos_map_set '1,1,8,1,0,63,255,255,255,255,255,255,255,255,255,255,255,255,255,255'
Surprisingly, letting DSCP and Cake manage traffic at the router makes wonders. I only prioritise as follows:
- DNS, DHCP and NTP —CS5
- Console traffic (UDP) —AF41
- GeForce NOW —game video stream AF41, game controls traffic EF
- Teams and Zoom —AF41
- SSH tunnel to Citrix boxes —AF41
- Parsec traffic —AF41
- SSH rsync.net backups —CS1
- VoIP —EF
And done! Not a single hiccup in my network, it doesn't matter how many video streams, video calls, phone calls, etc. I tried a combination of everything an latency doesn't suffer, calls don't loose quality, sound doesn't break up... works amazingly well. I should say that fq_codel is doing a great job on the WiFi side of things, though. And I suspect it is mainly the reason why everything works so efficiently.
3 Likes
excellent work to you! for my part I used the script of daniel and dscpclassify but I play mainly fps and I prefer by far the script of elan, it gives me such a speed in the games that 6 months after I remain always surprised by its effectiveness,
What is the elan script that you mention?
Mentioned in an earlier post.
so how and where can we get the elan scripts?
yes cake qos script 
How do you have it configured because in my case I tried it and it didn't work.
I'd like to make a rule for wifi calling (offered by most phone companies these days).
Is there a way to make a rule that captures traffic that uses
UDP - ports 500 and 4500
TCP - port 143
or is there a better way to achieve bumping the priority for wifi calls?
/etc/config/dscpclassify
config rule
option name 'Wifi calling udp'
option proto 'udp'
list dest_port '500'
list dest_port '4500'
option class 'cs5'
option counter '1'
config rule
option name 'Wifi calling tcp'
option proto 'tcp'
list dest_port '143'
option class 'cs5'
option counter '1'
Try this and check your firewall counter of that rule and see if the counter is increasing.
With this config traffic on the defined ports should go to voice tin (highest priority). Assuming you are using cake diffserv4.
If you you want to apply the rule only to a specific client you should add:
option src_ip '<your client ip>'
To check if the rules are working and DSCP's gets marked correct you can use tcpdump:
tcpdump -i <yourwaninterface> udp port 500 -vv
tcpdump -i <yourlaninterface> udp port 500 -vv
1 Like
Thank you! One more question.
These rules are defined in the egress direction. Does DSCP Classify ensure that the ingress traffic associated with this rule receives the same class or do I have to define a rule for incoming traffic as well?
I think that is the magic behind "DSCP classify" it uses the conntrack database to transfer DSCP labels from egress to ingress packets for the same connection... so no extra rules required for ingress... It does however limit you to using the same DSCP in both directions (but IMHO that is the sanest configuration anyway, I see little need for using different DSCPs).
4 Likes
Hello, i use windows qos to set egress dscp marks for my games, the only thing i want is that dscpclassify marks the ingress traffic for the same games. Is it possible to set all other ingress traffic to cs0 because my isp sends marked packets, if so what do i have to add to my config and do i even need option client_hints '1' ?
This is my simple config. @yelreve
root@OpenWrt:~# vi /etc/config/dscpclassify
config global 'global'
option client_hints '1'
option wmm '1'
Here is my br-lan tcpdump capture:
I marked my egress traffic on the pc (192.168.1.227) with dscp46(0xb8) but somehow it gets switched up and the game server (162.254.197.52) sends me dscp46 and my egress traffic is now cs6(0xc0).
1 Like
I know I just said, I lack first hand experience, but on a hunch i looked at the github code and as suspected it is option wmm '1' that elevates EF to CS6. IMHO this is not the ideal way to do this, instead one should use qos_map_set to change how EF is mapped to wifi access classes (this will also affect the upload direction from clients to the AP, while remapping will only affect the AP to station direction).
Side-note: since at least OpenWrt21 EF is already mapped to UP6 and hence to AC_VO by OpenWrt defaults, so it likely is safe on modern OpenWrts to use option wmm '0' and still get some WiFi prioritization. HOWEVER, on WiFi using the higher priorities not only decreases the delay for packets in the lower ACs but also will reduce the total achievable throughput (by limiting aggregation depth). This is not per se a bad thing, just something to keep in mind. Also to keep in mind is, WiFi is shared so using AC_VO on band X will affect the airtime access of all APs and stations using Band X in overlapping RF environments, so courtesy recommends in such situations to keep AC_VO (and to a lesser degree AC_VI) usage limited; obviously when one is the only user of a WiFi band one is free to slice and dice that airtime as one pleases.
3 Likes