I am using distribution of connections for my multiple IKEv2 providers and got always got the best spread with Per Connection Classifier (PCC) using the source port. The source port is for each connection out different. A good habit is to have the the last line function as a catch-all by removing PCC setting in that line.
PCC has do a calculation for each source port to know which line of the distribution connection line to use. That takes a bit longer than just like NTH does by counting. How ever I never could have a even spread using NTH and the catch-all line at the end of the list got always more hits.
So this morning I was thinking about this as many times before and then I got it. REVERSE THE ORDER.
Normally you would write for four connections: 4,1 4,1 4,1 1,1 (1,1 is representing the catch-all)
Working is now reversing the order: 4,1 3,1 2,1 1,1 (1,1 is representing the catch-all)
Explained. The first line takes every fourth of the connections because packet is 1 and because all lines have there 1 is effectively only looking at connections. The second line takes one out three leaving two. The next line takes one out two so leaving one. So one connection is left before starting again at the top of the list and this allows to omit setting the NTH because it will takes every connection passing. This is then the catch-all.
I use this as I wrote for multiple IKEv2 connection like you can have six connections at the same time with NordVPN. Those six can be multiplied to 18 if you are using different VPN protocols like IKEv2, OpenVPN TCP and OpenVPN UDP.
Finally I can archive an absolute even spread of connections by using NTH. If you want some randomness but still a almost perfect spread use PCC with source port.
How to use this? Have a look at the link in my signature, underneath this posting.
I was thinking now I can have complete even distribution about randomness. To archief that a Hash of the destination adress and source port is the best. However that not possible uding PCC and what is possible is both-addresses-and-ports.
The source address and distination address and destination port is included in the hash calculation but the same between each client connection they fall away leaving source port as big influencer. However the hash is a tiny tiny bit influenced by those three others. Maybe as much as using only the source port who in practice is not always a straight sequence, as other traffic as DNS.
I am going to use both-addresses-and-ports for now to have a bit of randomness and see how it goes.