I've made a new commit to allow users to support overriding the default zones, once on the new version you can use the following new global options:
config global 'global'
list lan_zone 'wiredclient'
list wan_zone 'wan'
Possible to attach a copy of your rule config for this?
Edit:
the following should work for you:
config rule
option name 'ICMP'
list proto 'icmp'
list proto 'icmpv6'
option class 'cs5'
option enabled '1'
Thanks alot, i was using the config example for icmp 
And how about having multiple lans? Are there any plans for the future? Is that even required? at least i can see the icmp working on multiple VLANs even if only one dev es selected in the config.
A general question: Why i need to specify icmpv6? should icmp use the family variable, too? eG like:
proto 'icmp'
family 'all' (which is the default in fw4 afaik)
Why icmp is somehow special here?
Is it normal that when I do a speedtest from another pc the latency on my gaming machine increases, or is there something wrong with my configuration?
This depends how much the latency increases... and how many flows are in use.
cake will round robin through all flows with queued packets in the current priority tier, so on a slow link with loads of active flows with queued packets the round-robin delay becomes noticeable.
The solution is to move the important packets AND ONLY the important packets into a higher priority tier and to make sure that priority tier is not exceeding its high-priority capacity, so no greedy capacity seeking traffic in that priority tier.
I keep repeating this, up-prioritization works best if used very very sparingly. In your case everything except your gaming traffic should be in BestEffort or Bulk/Background...
And depending on the available total capacity stuff that also might need elevated priority (e.g. video conferencing) can interfere with other high-priority gaming traffic. Prioritization in essence is really just sending some packets earlier than average, and that means other packets need to be sent later than average...
Try to decrease the bandwith in cake and see if ts getting better. Would be my first attempt
You can specify multiple zones by providing multiple list lan_zone entries like below:
config global 'global'
list lan_zone 'wiredclient'
list lan_zone 'wirelessclient'
list lan_zone 'lan'
nft handles icmp and icmpv6 as separate protocols, I can look into adding some setup logic to handle these more consistently with fw4.
Given that these are two separate protocols, that seems to be the sensible thing to do, no? 
However nft now allows you to specify the IP protocol as argument, compared to the more cumbersome way of having to use iptables and ip6tables binaries...
Hi @Kimcha, by default connections typical of P2P clients are identified using the following criteria:
In my own testing this is very reliable at catching P2P traffic and avoiding false positives, although I suspect that you could increase the default of 10 connections to a higher number and still catch the majority of P2P.
The threaded high-throughput services detection (parallelised downloads such as those used for Steam/Windows Update/speed tests) uses the following default criteria:
Again: Thanks a lot. gret project Sooner or alter i will work on contribute some more rules based on my old qosify setup. (eG WiFi Calling, some more gaming, etc)
config rule
option name 'WiFi Calling'
option proto 'udp'
option dest_port '500'
option dest_port '4500'
option class 'ef'
I would respectfully caution to create a big hierarchy of heuristics to up-prioritize any potential low-delay wanting use-case by default. Adding these as default-disabled examples is great, adding these as default-enabled heuristics seems risky... To repeat, up-prioritization needs to be used sparingly, if under saturating conditions all traffic ends up in the highest priority tier this just as having everything in BestEffort or not up-prioritized at all. For Prioritization to deliver under congestion, the high priority traffic needs to be capacity limited. Cake however does not do that for you (it opts to forego the priority of the higher tiers on overload, that is if the Video tin is above its capacity it will equally scheduled with BestEffort; the consequence of which is simply to only up-prioritize carefully and sparingly).
Thats absolute right. having some disabled by default examples is at least an option for most of the users. eG Wifi Calling is (in germany in special) a must have .. (our mobile network is shitty). Iam trying to minimize the amount of that kind of rules.
Another question: Any benefits of user diffserv8 ? I dont see them but iam far way of experienced in tha topic 
Well, if you need more than 4 priority tiers than diffserv8 is all that cake offers. IMHO it is unlikely that diffserv8 will be more useful than diffserv4, given cake's "downgrade-on-overflow" behaviour. My subjective take is, that cake's > BestEffort tiers are not useful for capacity seeking traffic (like data transfers), they might work well for naturally capacity limited traffic (which depending on total capacity can encompass stuff like vide conferencing) but how many of such flows does one have concurrently that also need to be differentially prioritized among each other?
For my personal uses, diffserv3 was enough (everything in BestEffort, manually move few select things to Video should the normal performance not be good enough*): one normal tier, and one each should the need arise to treat select traffic better or worse. But I accept that I am not your typical QoS hierarchy builder and understand that other's have different requirements, yet, let me try to summarize: diffserv8 might be useful if you actually feel limited by diffserv4's number of tiers...
*) So far with 50/10 and certainly now with 100/40 I do not see the need to prioritize anything, I still use layer_cake.qos so I could easily employ prioritization should I need it/desire to do so.
yes moeller is right, for my part I do the following,
ps5 is 2.160 the 443 ports are in bulk cs1 the dns in cs2 and my game is in cs4 in this example the game was using port 3074 because I was playing cold war
config pls
can we use either one of these options for gaming such as XBOX ? what are the pros and cons for switching between the two?
option class 'af41'
or
option class 'cs4'
The difference between the two is that they will end up in different tins when using cake diffserv4. You can read it in the cake manual:
Af41 -> Video tin
CS4 -> Voice tin
For latency sensitive stuff like gaming I would suggest you prioritize into voice tin.
As so often the answer is 'it depends'....
There are two things to keep in mind:
A) how do the selected DSCPs interact with the priority tiers?
e.g. for cake the DSCP to priority tier mapping is hardcoded and differs between the relevant modes (see e.g. here):
diffserv3 (re-odered from the reference so highest priority is on top to match diffserv4/8's order)
/* Simplified Diffserv structure with 3 tins.
* Latency Sensitive (TOS4, VA, EF, CS6, CS7)
* Best Effort
* Low Priority (CS1)
*/
diffserv4
/* Further pruned list of traffic classes for four-class system:
*
* Latency Sensitive (CS7, CS6, EF, VA, CS5, CS4)
* Streaming Media (AF4x, AF3x, CS3, AF2x, TOS4, CS2, TOS1)
* Best Effort (CS0, AF1x, TOS2, and those not specified)
* Background Traffic (CS1)
*
* Total 4 traffic classes.
*/
diffserv8
/* Pruned list of traffic classes for typical applications:
*
* Network Control (CS6, CS7)
* Minimum Latency (EF, VA, CS5, CS4)
* Interactive Shell (CS2, TOS1)
* Low Latency Transactions (AF2x, TOS4)
* Video Streaming (AF4x, AF3x, CS3)
* Bog Standard (CS0 etc.)
* High Throughput (AF1x, TOS2)
* Background Traffic (CS1)
*
* Total 8 traffic classes.
*/
As you can see from that the mapping for your two DSCPs differs quite a bit:
diffserv3:
AF41 -> Best Effort (normal)
CS4 -> Best Effort (normal)
diffserv4:
AF41 -> Streaming Media (second highest/Video)
CS4 -> Latency Sensitive (highest/Voice)
diffserv8:
AF41 -> Video Streaming (one above normal)
CS4 -> Minimum Latency (second highest)
So from a pure cake paerspective you really only need to figure out which diffserv-preset you want to use and then you only need a single DSCP for each priority tier.
B) For debugging and for elaborate multiple re-marking steps it can still be helpful to use multiple DSCPs that map into the same priority tier simply to still be able to make sense out of what traffic type this is and by which marking-rule it was handled (I note that this has its limits, for one 64 different traffic types is not that much, and cake only uses a small subset of these 64 possible, but still it can be helpful in packet captures to confirm that e.g. a Zoom call's packets got the desired marking).
I would suggest, you only up-prioritize the gaming stuff, and if you do that it does not matter whether you use the Video or Voice tin, both are above the rest of your traffic (and Video has a larger high priority capacity share and hence will tolerate bursts a bit better). If however you already have traffic that gets steered into the Video tin, and you want your gaming traffic to not be disturbed by that other priority traffic, then put the traffic you care most about into the highest priority tier.
I would however try to test each individual marking rule and only retain those that actually improve performance in your network, as I keep repeating prioritization works best if used sparingly...
What does it mean?
option class 'af41'
or
option class 'cs4'
after playing with both, 'af41' seems to be working well for me for COD games. it feels like the response time is much faster compare to when 'cs4' is used.
With diffserv4 CS4 maps to the highest priority tin (Voice), while AF41 maps to the second highest (Video). The Voice class gets 25% of the totak capacity as guaranteed high priority allotment, the Video class 50%.
Assuming that your game does overflow neither classes capacity, AND you have no other high priority traffic AND you wash your DSCPs on egress, your game should be behave identical with CS4 or AF4. If the game does behave differently you should check these three assumptions. Without additional data and observations it is hard to come up with a decent theory what is happening.
Also worth repeating: prioritization is essentially a zero sum game, for every packet treated to lower delay some other packet(s) will be queued longer and experience longer delays. That means that if you have few high priority packets and loads of normal best effort packets, prioritization will work well, however if you have only high priority packets (for the same priority tin) prioritization will not work all.