Well, I certainly would test whether I actually need special rules for this at all. BUT I am also a lazy person and hence will accept a bit more slack im my QoS setup than gamers in general, if it saves me the tedious work of designing heuristic rules and (even worse) maintaining those rules (aka check continuously whether the employed heuristics still work as intended).
But I am also conscious that this is a matter of subjective policy and I will not go and tell you to not make detailed rules in your network (as these can perform better than the naive approach I am taking assuming one is willing to pay the maintenance cost). I would just make sure that each rule actually improves things (as each rule will have some cost in complexity and potentially in computation).
I believe this to be an example of beautifully custom tailored QoS rules that probably work/worked very well for the OP, but I would be hesitant to copy and use these verbatim without confirming for each individual rule (or set of related rules) whether they are a) still required (in light of the sparse flow boosting in fq_codsel and cake) an b) whether they still work as designed.
Traditionally CS7 was reserved for critical networking infrastructure, for that to work the devices actually interpreting CS7 need to be super selective from whom to accept CS7 markings in the first place (otherwise any client running "sudo ping -f -Q CS7 your.critical.networking.device" (pseudo-code only) can basically DOS the "management plane"). As far as I can tell cake's diffserv3 and diffserv4 will both lump CS6 and CS7 into the same priority tier. Both the precedence and the diffserv8:
static int cake_config_diffserv8(struct Qdisc *sch)
{
/* 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.
*/
static const u8 diffserv8[] = {
2, 5, 1, 2, 4, 2, 2, 2,
0, 2, 1, 2, 1, 2, 1, 2,
5, 2, 4, 2, 4, 2, 4, 2,
3, 2, 3, 2, 3, 2, 3, 2,
6, 2, 3, 2, 3, 2, 3, 2,
6, 2, 2, 2, 6, 2, 6, 2,
7, 2, 2, 2, 2, 2, 2, 2,
7, 2, 2, 2, 2, 2, 2, 2,
};
and the precendene:
static const u8 precedence[] = {
0, 0, 0, 0, 0, 0, 0, 0,
1, 1, 1, 1, 1, 1, 1, 1,
2, 2, 2, 2, 2, 2, 2, 2,
3, 3, 3, 3, 3, 3, 3, 3,
4, 4, 4, 4, 4, 4, 4, 4,
5, 5, 5, 5, 5, 5, 5, 5,
6, 6, 6, 6, 6, 6, 6, 6,
7, 7, 7, 7, 7, 7, 7, 7,
};
scheme will honor CS7 (albeit differently).
That is odd, TOS (type of service) was an older recommendation for the usage of a specific set of 8 bits in the IP header. With the introduction of ECN, two of these 8 bits have been rededicated, hence ideally plain 8-bit TOS is obsolete and should not be used anymore.
Possible, but not super likely (as far as I know, it is considered good network hygiene to remap incoming TOS/dscp values if one uses these in one's own network.)
TCP congestion control algorithms will get into bad territory if the delay gets too large, I always assumed that means weird oszillations but never bothered to look into the details.