Qosify: new package for DSCP marking + cake

I have a few mentioned in this post:

Thanks, I'll check them out.

some further testing and additional feedback:

  1. case of competing configuration like
tcp:80 besteffort
tcp:443 besteffort
dns:*.example.com video
# www.example.com = a.b.c.d
a.b.c.d voice

accessing http://www.example.com what will be the dscp marking? besteffort due to tcp:80 rule or video due to dns match or voice due to ip match? first or last matching rule will win? or all will be applied in random/priority(e.g. port rule is lowest, ip highest)/line number order? if split config to three files will that matter, are they loaded and applied in filename order?

  1. the default configuration installed with the package sets bulk_trigger_pps 100 for voice class, a usual g711/g729 call is using 20ms samples so that's already 50pps! not sure if this feature is there because of Call Admission Control (CAC) was in mind, it is nice feature but quite dangerous as can silently re-mark high priority traffic, so definitely more explanation on pro/con to use this feature would be great. I.e examples when to use or not use.

  2. option disabled 0 could it be renamed to option enable 1 like in case of other UCI configs please?

3 Likes

any way to improve latency?

The DSLReports Speed Test has been badly broken for a while now.

I would recommend the Waveform BufferBloat (and speed) Test...

I was doing some modifications in dscp but I still have bad latency so I thought it might be my ISP so I did tests. So for this I made sure to create a WAN -> LAN (wifi w1) rule.

And ... surprise! my ISP covers dialing by DSCP and 802.1p, Wireshark tells me that all packets go through CS0.

LE and CS1 are the same?

no see link

in what situations can I use LE ?

I have good latency as seen here https://www.waveform.com/tools/bufferbloat?test-id=c078af0a-2977-4f43-b8bf-886d2e67b9fa and here http://www.dslreports.com/speedtest/70306444
But when I play, the latency increases, I don't know why or some port has precedence or I should modify something else

The LE per-hop-bahaviour is aimed at traffic with less then the normal best-effort priority, like CS1 was. Since knowing packets that can be dropped/delayed without complaints can be helpful for network operators such a dscp has the potential to make it over the internet unmodified.
CS1 has the problem that some existing devices interpret CS1 to have higher priority than the default CS0/BE, potentially inverting the intended purpose of a CS1 marking. In comparison LE will be most likely interpreted as best-effort, avoiding the 'priority inversion' sometimes seen with CS1.

But as always your own prioritization set-up needs to support a specific PHB/DSCP to be useful.
cake, IIRC, treats both CS1 and LE as lower priority markings and stees such packets into the 'bulk' tin.

As a consequence you can use LE to mark packets that you do not care much about, and that you do not want to get in the way of more urgent traffic. Examples of such low priority could be e.g. bit torrents, or background downloads of large data that you do not need urgently.....

Hope that helps.

1 Like

ah I didn't know but I still have bad latency in games, should I configure something else?

So conceptually all you can do on your side is:
0) configure sqm with shaper settings that give you low/acceptable bufferbloat measures at all times (you want to use your link for gaming)

  1. Figure out how much traffic ypur game creates in both directions, looking at both longer term average rate and short term bursts

  2. set up a prioritization schme in which you only prioritize gaming packets and you make sure that the game-priority tin/tier has a sufficiently guaranteed rate-share such that it comfortably will fit the average rate from 2) and that is also large enough to accept the burst measured in 2)

  3. check whether there are signs of router exceeding its CPU capacity during gaming, if yes replace router with a more powerful unit.

As far as I can tell that is essentially all you can reasonably do at your router....

I assume you already controlled the non-router potential issues like:

  1. your gaming computer being fast enough for the selected game and graphics quality setting

  2. not playing over a sharwd WiFi or 100Mbps fast ethernet hub wirh other computers connected

  3. not having any multicast storms affecting your gaming computer

  4. decent routing/peering between your ISP and thevgaming servers (you might be able to affect/change/improve this routing by using a VPN that is both well connected with your ISP and the servers)

I have a rpi4b router so more powerful I do not think it is necessary something that I noticed is that when I download files of more than 2gb the bandwidth speed is not reduced or it does not go in bulk

therein lies the problem, i think maybe i need to configure something else

Sorry, I have not installed/tested qosify on any machine yet and will not be able to help here... My proposal however was not so much de-prioritising bulk traffic (albeit that might be a decent idea) but selectively only prioritizing your single game traffic (if that can be classified without too many false positives).

if you wanted to do something like this, how would you do it?

Fist figure out what identifying properties for your latency-sensitive gaming packets you can find. If it is port numbers you should be able to use qosify (as far as I understand) but make sure you start out with ONLY putting your gaming packets into a higher than best-effort priority tin, while leaving everything else in best-effort. (I would recommend to use diffserv4 and the Video tin as that will give you 50% of your total capacity for priority traffic (diffserv3 and diffserv4's Voice tin will only allow up to 25% of the total limit for high priority traffic, which might be too little if the link is slow and gaming traffic is bursty)). But really the trick is to start testing with only a single game's packets classified into high priority.

I use this class for now, the latency is good, but when everyone uses the network, the latency already varies a lot.

config class high_throughput_data
	option ingress AF12
	option egress AF12
	option dscp_prio AF11
	option prio_max_avg_pkt_len 1200
	option dscp_bulk LE
	option bulk_trigger_pps 700
	option bulk_trigger_timeout 20

As far as I can tell all of these map either into the Bulk or the Best-effort tin, so you still need to move your game packets into the Video tin.

Yes, full saturation is a bit problematic, remind me again, what speed does your link allow?