Yes, in piece_of_cake.qos cake is configured besteffort which means there is only a single priority tier and all flows are treated equally independent of DSCP values, but unless the wash keyword is set, cake will not touch the DSCP value at all, if it is set cake will re-map all DSCP values to 0/CS0.
In layer_cake.qos cake is configured to use 3 different priority tiers and will sort flows/packets into these tiers based on the value of the DSCP bitfield, if the wash keyword is set, cake will first sort into the corresponding priority tier and then re-set the DSCP bitfield to all zeros.
The behavior of the wash keyword was selected to allow using internal DSCPs to steer packets into the desired priority tiers without leaking these DSCPs upstream (e.g. some ISPs treat some DSCPs differently, like dropping/rate limiting CS6 or CS7).
-
Is this package combination of luci-app-qos / luci-app-nft-qos and luci-app-sqm
-
When will this be added to official repo ? If it is already what is the package name? I can't find it here
-
Also luci-app-qos vs luci-app-nft-qos ?
Neither, this package sets up its own cake instances and uses eBPF to allows setting DSCPs on external address and ports as well as server names and more.
What is the exact question? But independent of that I have no first hand experience with either so will not be able to help.
How much faster is eBPF as compared to nftables? Since unless I'm mistaken at least everything qosify does and more can be done in nftables and tc. So I'm curious.
QoSify have SQM and QoS ?
No, eBPF runs before the ingress cake qdisc so can re-mark DSCPs on ingress in a way that cake only sees the re-marked DSCPs. In theory nftables also has a hook in the right place but I never tried that and it will also not have access to internal IP addresses and ports (just like qosify). eBPF is considered to be a potential contender as nftables backend in the kernel, so there are some arguments for eBPF.
No. SQM is the name of a package (actually the names are sqm-sfcripts and luci-app-sqm) that offers a pretty easy set-up of traffic shaper and competent AQM that does not require deep networking skills to configure, it does not aim at ultimate configurability, but sane defaults and as few toggles as possible. (However sqm-scripts offers a machinery to run specific qs scripts so for anything more complicated you can write your own script and use sqm's existing framework/machinery).
QoS is just a generic acronym for Quality of Service. There is an OpenWrt package IIRC called qos-scripts that also sets up a traffic shaper + AQM combination. qos-scipts offers a few options that sqm-scripts does not offer, but the last time I used qos-scripts myself was around 2013, so I have forgotten most of the little I knew.
Setting DSCPs with nftables on ingress is easy with the ingress hook and one can construct IFB in nftables for cake to operate on. I tried that once and worked fine. If one needs internal IPs then just create ifb that takes in flows from a bit further down rather than wan.
But what's the scenario where one doesn't want to use conntrack restore anyway? Since absent such a scenario what's the use case for altering DSCPs on ingress? That's why I don't bother altering DSCPs on ingress and just set them in nftables on upload via forward hook.
Doesn't one want both directions of connections to share same DSCPs? And this we set on upload side and have conntrack restore do the rest and Bob is your uncle.
I guess I'm still hazy about the use case for qosify. Maybe eBPF is a bit faster?
In the scenario where you want to override everything on the router and where you want different DSCPs for the forward and the reverse path.
But you need to do this first otherwise this does not help. This is not where sqm-scripts instantiates its IFB.
If that works for you great! I would assume, would I actually need to resort to selective DSCP marking this would work for me as well, but as above it will cause issues when different DSCPs for ingress and egress are desired.
You need to ask others than me 
while I respond to a lot of the QoS threads, I actually use QoS myself very sparingly, currently not at all.
As I said there are discussions of making nftables use eBPF as backend in the kernel which seems to imply that there are advantages to eBPF, but I can not enumerate these.
Also I would say if one's desires fall within qosify's feature set this is easier to configure than nftables, or so I believe having used neither qosify nor nftables myself.
QoSify has both Anti-Bufferbloat (que management) and QoS ?
I am not sure this question is as precise as I would like it, but mostly yes.
Qosify combines the cake qdisc (which is a combination of traffic shaper with and AQM , and an flow queueing scheduler allowing either 1, 3, 4 or 8 different priority bands, cake uses DSCPs to sort packets into these priority bands) with an eBPF system to set DSCP fields according to some (limited) rules.
Traditionally such hierarchy of priority bands and sorting of packets by some criteria has been used to assure Quality of Service (QoS).
I think the main reason people are using it is because it is easy to set up and because it can add DSCP tags based on the destination domain.
But I agree with you, applying the same DSCP using connection tracking would be better.
Once dnsmasq is updated to 2.87, which supports nftset (like ipset for domain based firewall rules), then perhaps your proposed solution can fully replace QoSify.
Very interesting. Does this mean that dnsmasq can be leveraged to generate an IP set against which nftables can check to assign DSCPs for a specific set like all those to a particular domain?
What's the use case for the latter? I wondered about rendering bulk those IoT destination domains?
Presumably not for differentiating between internet sites. One imagines if internet sites aren't loading well then the qos implementation is kinda borked anyway, no?
I gather that DSCPs are to be used extremely sparingly for very low bandwidth situations like under 10Mbit/s where one needs to choose which service(s) out of several competing services should get punished in favour of services that should not get punished like Zoom or Teams.
I'm trying to think out how one would meaningfully leverage working with domains to this end.
The way I use DSCPs is that I set up a simple nftables script go assign certain DSCPs (bulk for IoT devices by MAC address; voice for DNS) and save all DSCPs to conntrack on upload. And then I have tc restore from conntrack DSCPs on download. This way either router and/or LAN clients set DSCPs for connections. And I have my Windows work machine assign voice DSCPs for Zoom and Teams in order to prioritise those in times of very low bandwidth.
I wrote a simple nftables file, service script and hotplug script for the above, which is available here:
Differentiating traffic using a common remote port (e.g. 80, 443), but needing to deprioritize Windows Update traffic and boost YouTube videos, as a crude example.
Ah that's helpful. Thanks.
One caveat with that approach is that in oue heavily CDN's world the same IP might serve services of different importance, in which case I assume the last rule wins...
Another one is that some services don’t use consistent ports. For example, GeForce Now. But you can prioritize it based on the host names.
How to install Qosify ?
as any other package:
if the repos bind to your release version include the package then simply opkg update && opkg install <package name>
What is the package name ?
its called qosify