I'm using QoSmate with CAKE. I would like to know if I have to use the wash command on ingress and egress or is it not necessary?
If you don't wash the input and output, I saw something related that hudra said that the rules won't work for dscp classification. On the github site it is like this:
Enable WASH in both directions (WASHDSCPUP and WASHDSCPDOWN)
Your network, your rules. It really depends on what do you want to achieve, so here is a quick reminder of the consequences:
Ingress: wash will take the existing DSCP (be it coming from the internet, or from the contrack action for tc) and steer packets into the matching cake priority tin (if you use besteffort there is only a single tin), and then it will re-mark the DSCP bitfield to CS0/DF. And in your LAN all packets from the internet will have CS0/DF and will be treated to default forwarding. If you do not set washpackets will keep their DSCP and this might affect e.g. the selection of the access class in WMM WiFi (there are four access classes by default with different stochastic priorities)
Egress: wash will take the existing DSCP (be it coming from your end hosts or from firewall/nftables/tc rules) and steer packets into the matching cake priority tin (if you use besteffort there is only a single tin), and then it will re-mark the DSCP bitfield to CS0/DF. This way you do not leak DSCPs into your ISPs network and the internet. One reason for doing that is, that some ISPs do treat packets with a DSCP different from CS0 differently, but typically not by giving them higher priority/lower latency, but rather showing increased latency/jitter and occasionally als higher packet loss rates for marked packets...
Whether you should set wash and in which directions is a decision each network admin needs to take for their own network.
2 Likes
Very well explained!
If it’s okay with you, I’d like to include it in the README. I’ve been meaning to put together a proper explanation of the wash function for a while now just to avoid having to go over everything again every time someone asks about it.
One important addition to mention though is that qosmate (at least in some constellations) actually overwrites DSCP values on ingress coming from the ISP.
For example:
If ingress washing is active and HFSC is set as the root qdisc, all packets are initially marked as CS0 when they pass through the dscptag chain (the chain where the marking is happening).
Packets that match a qosmate rule will of course be tagged with the appropriate DSCP value.
Because the DSCP value is written to conntrack and then restored on ingress, this means that in this scenario , all packets end up either with CS0 or the DSCP assigned by a rule, effectively overwriting any DSCP set by the ISP.
Sei mein Gast 
The text is yours...
Sure, I tried to convey this cryptically with " or from the con[n]track action for tc" making this more explicit is certainly a good idea.
1 Like