Yup, that's exactly what it does. So this relies on the traffic having a DSCP marks set when they enter the wireguard interface.
Well, if qosify runs on the physical WAN interface, it'll look at the packets as they appear there, which means all wireguard traffic will just be identical encrypted packets. It should be possible to run both qosify and preserve-dscp, though; either by making sure preserve-dscp runs first (on the physical interface) and that qosify leaves existing DSCP marks alone, or by running preserve-dscp last and having it overwrite any marks set by qosify. I don't know to what extent this will require modification of either.
As for setting the marks on the traffic inside the wireguard tunnel, the qosify BPF classifier could run on the wg interface as well setting the marks there (but it shouldn't install a cake instance on the wg interface, obviously).
This has been proposed multiple times, and I wouldn't hold my breath. Preserving DSCP marks is an information leak and Jason (the wg maintainer) is rather opinionated about not doing that
The smoothest thing would probably be to teach qosify about "inner interfaces" and incorporate the skb->hash lookup logic of preserve-dscp into the qosify BPF program itself. Should be fairly straight-forward to do, I would expect.
Basically, you'd add an inner_interfaces config parameter to qosify, which would cause the classifier BPF program to be loaded onto those interfaces, but instead of setting the DSCP mark directly in the packet, it would store the DSCP value in a map keyed on skb->hash. And then amend the BPF program running on the outer interface to first lookup the hash in the storage map and read the DSCP mark from there, and if nothing is found, do the regular classification (which would then apply to anything not in the wg tunnel).
In theory could this work in the other direction for download too? I mean by building up table post decryption and then working backwards to apply the marks pre-decryption? So that is, decrypt the packets, have DSCP marks associated with the decrypted packets set up, then apply those to the encapsulated packets?
Because if so, then CAKE could just always be applied on WAN and IFB from WAN in the usual way without having to apply gymnastics where there is a mixture of encrypted and unencrypted flows say in the case of VPN pbr.
In any case, how would this preserve DSCP marks approach as provided in your script compare to simply just setting up an appropriate IFB with all the upload flows combined including those destined for encapsulation prior to the encapsulation?
For download I already combine flows from WAN and my WireGuard interface VPN into an IFB and apply CAKE on that.
So I suppose for upload I can also combine flows from br-lan and br-guest destined to go out to WAN or VPN.
In both cases the overhead is wrong for some of the flows because you can't specify more than one overhead per interface, right? But I don't know if that matters very much.
Not without breaking causality
It works on egress because you start out by hashing the packet, and then specifically preserving that hash through encryption (which is something that was added to the wireguard code). On ingress, you only have the encrypted packet to look at, and you don't know which flow it belongs to until you've encrypted it.
Hmm, that's an interesting approach; yeah I guess that could work.
The main thing you get from correct overhead calculation is precision in shaping. So if the overhead is wrong, the actual rate on the wire is slightly off from the setting in cake. This means you can overshoot and end up filling up the bottleneck queue even though you're trying to shape below it; you can compensate for this by setting the shaper to a slightly lower rate (or setting a conservative overhead value). This will waste a bit of bandwidth, but can work fine to control latency...
Since @Lynx uses his own autorate code getting the overhead wrong is not a big deal for him. However I recommend to configure the larger wireguard overhead as that would even work correctly in a static shaper configuration.
Hi @elan , first of all, Thank you so much for sharing your configuration of Qosify... I have been having issues playing online a game that uses P2P and weird udp ports (mostly used for VOIP).... Anyway... I need a little bit of help if you can. The game I play classify the udp packets (in game) as Expedited Forwarding which is great since with your config it should go straight to top priority. The challenge is that we use 8x8 at home (softvoice system) that is classified as CS7 and if I'm not mistaken, it takes priority over EF. How can I assign CS7 manually to a lower tin?
With cake as qdisc you can not really change the DSCP to priotity tier mapping unless you patch your kernel. You should however be able to create a filter rule to remark 8x8's packets to something you prefer over CS7.
By the way in diffser3 and diffserv4 both CS7 and EF are mapped to the same high priority bin, for diffserv8 CS7 maps to a higher priority than EF.
Ciao @anon78773196, yes that was just for testing since those ports are dynamic, I don't understand how to control the outgoing packets... and whenever we receive a call it messes up my gaming.
For 8x8 you might be better off trying to create an ipset for the respective VoIP servers (assuming that they centralize voice processing, if they allow direct peer to peer VoIP traffic this will not work).
That is quite a wide range, which makes is likely that you get other traffic remarked that you potentially did not want to remark.
What operating system are you using for 8x8 calls? Maybe that could be configured to set/change the desired DSCPs directly?
I think this is something that qosify allows:
dns:*.example.com video
which will instantiate an ipset by itself fed from all DNS requests to domain names that match *.example.com and they will be treated to the configuration named video.
Mind you I have never used qosify myself so I am just repackaging information from this thread, so things might not work as I expect...
Here are my notes for getting DSCP marking operational for windows:
Seems to work, and I confirmed via tcpdump that putty's ssh packet originating from the windows VM host actually used DSCP 46 (aka EF). I note that powershell needs to be run as administrator, and the policies do not end up visible in Local Group Policy Editor. "-PolicyStore ActiveStore" will not survive a reboot, but for novice users that might be nice so a reboot cleans the slate in good windows tradition. I assume that after initial testing one could omit the "-PolicyStore ActiveStore" directive and store tested configs more permanently.
So that script is quite comprehensive and probably well tested. But keep the following in mind:
Prioritization works in that some packets are treated to better than average service (almost always this boils down to less queueing delay), but for that to work some other packet(s) will need to be delayed somewhat more. This works OK if the volume of packets to prioritize is noticeably smaller than the volume of packets that can be delayed. E.g. if you prioritize all packets that has the same effect as prioritizing no packet at all.
So if you use the referenced script try to make sure you only ever up-prioritize stuff you really really want expedited (down-prioritization is less problematic, but the guaranteed rate for the background queue is really small, so anything you want to transfer somewhat timely is better housed in the besteffort tin than in the background tin, however all transfers you really do not care much about the completion time of above "eventually" are great candidates for the background queue).
this is my personal opinion i am a ps5 player and soon PC and my games run very well with this script, just fill your values to 85% and your connection type overhead
Great explanation, I'm a novice and I think I'll continue with qosify, it really is the easiest to configure and I haven't had any problems because my use is very basic.
I just tried installing this script from the original post, and I am getting 20ms bufferbloat on download... with qosify I was at 0ms and I'm trying to understand why...
