Yes, I have been thinking all night yesterday about this and have come to the same conclusion.
Essentially, cake ensures extreme fairness on the network. The bandwidth is evenly divided between all hosts' and their flows'.
The QoS feature allows us to introduce some unfairness to the system.
And while automated rules are tempting, they can also backfire. And personally, I want to be hands off in my network after I set it up. I don't want to constantly worry if some download is slow that it's caused by some automation gone haywire.
So I am working now on a config where best effort is the default tin, known bulk transfers are put into bulk and some things are prioritized.
Thank you, but why do you think that there is an error?
My understanding is that the egress wash option removes the DSCP tags AFTER cake's processing, but before the data is sent out to the ISP.
The ISP may or may not wash the DSCP maks. There is some concern that if you abuse DSCP maks that the ISP might penalize your traffic, but with my rules I am not concerned about that.
I also don't care if the ISP honors my DSCP prioritazation. If it does, then great. If it's doesn't then that's fine with me too, because I mark the packets for cake and not for the ISP.
And one more question... Does the bulk_trigger_timeout option work for you guys?
I added this to my config/qosify:
config class video_network
option ingress CS3
option egress CS3
# Make sure SFTP transfers are not prioritized
option bulk_trigger_pps 100
option bulk_trigger_timeout 10
option dscp_bulk CS1
And in my qosify/00-defaults.conf:
# SSH
tcp:22 video_network
The goal is to prioritize regular SSH shell traffic, but also to ensure that an SFTP transfer doesn't end up being prioritized.
When I sniff the traffic I can see that the my SSH shell traffic is correctly prioritized. SFTP transfers start out prioritized, but then move to best effort.
So far so good, but...
When I execute cat /var/log/dmesg, the shell data flow switches to best effort. But even if no other packets are exchanged in the flow for more than 10 seconds, it doesn't switch back to video.
I also tried to set it to 2 and 5s, but had the same result.
Am I misunderstanding the options and this is the expected behavior @nbd?
Regarding your DNS findings, you also need to be aware of the dns_c: syntax used for CNAMEs. Mostly, QoSify is watching A or AAAA responses for matching, but if the domain is actually a CNAME, you might want to try adding a dns_c: entry for the domain.
QoSify is only going to see traffic going through the WAN interface (by default). Is this SSH test between a LAN client and the router's LAN interface? If so, QoSify would never get a chance to classify it at all.
Thank you, I have edited my original post to add a note about that too.
To check egress traffic I have been sniffing on the wan interface on my router through SSH. This allowed me to see DSCP marks for upload traffic, but not downloads.
To see ingress traffic marks, I have been sniffing on the ethernet interface of my mac.
Both worked well as long as the wash option was off.
Onedrive used the hostname api.onedrive.com, which resolved to...
❯ host api.onedrive.com
api.onedrive.com is an alias for common-afdrk.fe.1drv.com.
common-afdrk.fe.1drv.com is an alias for odc-commonafdrk-geo.onedrive.akadns.net.
odc-commonafdrk-geo.onedrive.akadns.net is an alias for odc-commonafdrk-brs.onedrive.akadns.net.
odc-commonafdrk-brs.onedrive.akadns.net is an alias for common.be.1drv.com.l-0003.dc-msedge.net.l-0003.l-msedge.net.
common.be.1drv.com.l-0003.dc-msedge.net.l-0003.l-msedge.net is an alias for l-0003.l-msedge.net.
l-0003.l-msedge.net has address 13.107.42.12
The connection was made to 13.107.42.12 and correctly classified as bulk traffic.There were no other DNS requests for it.
Dave Täht dtaht
October 24
Kimcha:
Essentially, cake ensures extreme fairness on the network. The bandwidth is evenly divided between all hosts' and their flows'.
The QoS feature allows us to introduce some unfairness to the system.
exactly!! But I haven't said it as well as that.
[SM] I agree, I sometimes call this "need for targeted unfairness" and qosify offers a convenient way to target (although it would be nice if it would offer rules based on internal IP addresses as well).
@nbd, here's another feature request and "knob to tinker with": Allow the user to set separate values for dscp_default_tcp and dscp_default_udp for egress and ingress.
For example, I would like to set all DSCP on ingress traffic from the ISP to besteffort, because I have seen some marked as bulk even though it shouldn't be.
But at the same time I want to preserve the DSCP maks from my network, since some applications do set the correct DSCP maks (such as zoom).
Sorry @nbd, another question for you. I also don't seem to be able to get the prio_max_avg_pkt_len feature to work.
My config is:
config defaults
list defaults /etc/qosify/*.conf
# Don't override DSCP classes
# If none of the rules in `/etc/qosify/*.conf` apply,
# keep the DSCP class the application (egress) or ISP (ingress) set
option dscp_icmp +besteffort
option dscp_default_tcp +besteffort
option dscp_default_udp +besteffort
# Put small packets into the video tin.
option dscp_prio video_broadcast
option prio_max_avg_pkt_len 500
config class video_broadcast
option ingress CS3
option egress CS3
But I don't see any traffic going into CS3 when I sniff it. I also tried setting prio_max_avg_pkt_len to 1500 and even a high value like that didn't create any traffic in CS3.
Thank you, that's a good idea. But I just tried it and it didn't work. No matter what variation of options I used, whenever I set the dscp_default_tcp option both ingress and egress were overwritten.
So for now I am not cleaning the incoming and outgoing DSCP values (same way "vanilla" cake would treat it).
Ah, good to know.
In the meantime you can use the DNS option, which I have verified to work by sniffing the traffic:
Openwrt builds that include qosify and also which are set to use the internal bpf llvm toolchain (BPF_TOOLCHAIN_BUILD_LLVM=y) will fail during make download with qosify unless a make toolchain/install is performed first. This combination of qosify and internal llvm is common in distributed official config.buildinfo files.
make[1]: [package/Makefile:115: package/network/config/qosify/download] Error 2 (ignored)
make[2]: Entering directory '/home/kfitzner/devel/openwrt/package/network/config/qosify'
bash: line 1: /home/kfitzner/devel/openwrt/staging_dir/host/llvm-bpf/bin/clang: No such file or directory
bash: line 1: [: : integer expression expected
/home/kfitzner/devel/openwrt/include/bpf.mk:71: *** ERROR: LLVM/clang version too old. Minimum required: 12, found: . Stop.
make[2]: Leaving directory '/home/kfitzner/devel/openwrt/package/network/config/qosify'
time: package/network/config/qosify/download#0.16#0.02#0.18
ERROR: package/network/config/qosify failed to build.
It looks like qosiffy's makefile s trying to see that llvm is present at the make download stage. Most of the toolchain isn't built yet,though, This seems like a bug to me.
I am using this package with my pi4 router. But sometimes when I start a game my pings are very high and fall back to normal after few mins of gameplay but today my ping was stuck at 999 and I ran speedtest to check my speed is ok from ISP side and it was all good, came back to game and ping was again normal.
Is this normal behavior?
out of curiosity: on 34/18Mbit line why are you using diffserv8 model? what does not fit into diffserv4? in case of relatively modest bw with diffserv8 you'll get very small tins.
