Different approaches...
Quosify:
- uses an efficient eBPF approach to change (ingress) DSCPs based on simple rules before ingress qdisc get hold of the packets.
- can interface with dnsmasq to essentially fill its own ipsets from dnsmasq DNS data, so can filter on domain-names (IIUC it will filter based on IP addresses returned for the domain names, so it is possible to get false positives if different websites share the same IP address, which with the popularity of CDNs is not totally theoretical)
- is currently limited in that it can "filter" on either IP addresses or external port, but not on combinations of both
- can not use internal port numbers
- can not use internal IP addresses (it operates before network address translation happens)
cake-qos-simple:
- uses the tc action that allows to restore the DSCP per connection based on the DSCP stored in the kernel's connection tracking database
- it uses nftables to actually copy DSCPs from egress packets into the conntrack database (which currently is not super elegant due to nftables limitations)
- by using nftables it can easily filter on ip-address:port combinations
- by using nftables it can easily filter internal and external IP addresses and ports
- can operate with DSCPs set by applications or by the router (a policy decision)
So there are plenty of differences between the two...
If at all cake-qos-simple is comparable to DSCP classify as both use the same elegant tc action approach, that @ldir invented. How these two differ I can not really tell you, as I tried none of those myself (both due to lacking a compatible router, my turris omnia is still on OpenWrt21 based TOS6 and hence offers neither of the three approaches and due to lacking the need). Conceptually, I think that the conntrack method is more elegant but qosify likely is more efficient...