How to enforce certain DSCP tag to certain destination and avoid DSCP remapping?

is there a way to avoid DSCP remapping by isp or ceratin route and is there a tool that can show me where dscp remapping occur

thanks in advance

  • It may help if you mentioned that you've asked about DSCP before (I'm not sure why you don't do this)

For others: What dscp classes or tos values that have the lowest priority and highest priority?

No. As noted in the other thread, you only control your rotuer, the ISPs control theirs.


It occurs on your router (i.e. the only router in the path you can control).

(...BUT...I have a feeling you're referencing this:)

As I noted:

What do you expect to occur to your traffic when you play with the DSCP tags???


i want to setup cake qos correctly with dscp


OK, cool! :smiley:

Now, can you explain why/how you believe Cake QoS is related to DSCP?

Then I'm sure we all can help.

tagged dscp help cake to identify packets which need to have high priority ? for example ef EF
(high priority) and CS1 (low priority)

1 Like

Yes, I know that about DSCP; but that information is unrelated to Cake QoS.

  • Are you having issues with installing/configuring Cake QoS?
  • Are you under some impression that Cake QoS and DSCP are identical???

:spiral_notepad: To be clear: Cake QoS and DSCP are unrelated technologies; but they both allow QoS:

  • DSCP - thru the ISPs routers via a packet tag
  • local QoS - thru prioritization of bottlenecked packets on the WAN port, dropping lower ones
1 Like

What you need is Qosify:

P.S. Qosify is now available in OpenWrt 22.03.

1 Like

Presumably SQM w Cake (or other assorted options) is still an option


I wasn't referring to an app, I was referencing use of tags as in the previous thread (both never motioned use of Cake until asked).

That is a good suggestion for the OP.

I take offense in that, period. Qosify is great, but not a strict superset of what sqm-scripts offers, while sqm-scripts (is also great) and not a superset of what qosify does. Both are tailored to different use-cases, and IMHO both have different strength.

I understand that you like qosify a lot, and that is great, but please at least give a rationale why you believe that qosify will do what the OP wants... (apparently he wants his ISP to pass DSCPs unmodified, so IMHO what he needs is a service level agreement (SLA) with his ISP, if we take his request literally).

Now, if he should be happy with DSCP marking his on ingress traffic, then I agree qosify looks like currently the best way to achieve that in a convenient way. (But then again there is nothing he could not also achieve by adding a few tc filter commands to later_cake.qos, but that requires more effort).

Standard prioritization disclaimer (directed as the OP):
Using DSCPs is only ever useful if you want to treat packets differentially based on the exact DSCP value. If you goal is to change priorities then please keep in mind:
Prioritization is a zero sum game, that is every for packet that get preferential faster delivery other packet(s) will need to wait longer. That has one big consequence:
You can only prioritize a fraction of of your packets, because if you try to prioritize too much packets (at the same time) the prioritized flows start to compete with each other, in the extreme trying to prioritize all packets essentially is equivalent to not prioritizing at all.


Sure appears to be a veth there for me.

No, it will not. With the described cake settings all flows of that host are treated equally, if you allow your torrent client too many simultaneous connections, then the other flows will see maybe a smaller total capacity share than you expected. But in all honesty, if you are unwilling/unable to give the torrent application its own IP address OR unwilling to configure the torrent client to keep a sane connection number limit, you might have a point then fiddling with DSCPs and priority levels might appear easier.

That however is still essential, qosify adds a great tool, but it does not replace the need to know what one is doing. (Prioritization being a zero sum game you need to know where your winners and where your losers are going to be).

That is one option, but keep in mind that unless you permit totally crazy number of concurrent torrent flows, cake's/fq_codel's sparse boosting will still be active and help interactive uses along.

BS, you can do all of this away with a bit of arcane TC filtering, as long as your traffic has easy identifiers as port numbers there is NO need for the VETH redirection (that said a VETH has similar cost to an IFB, but the VETH interface require to configure routing, while IFB does not, as you know because you implemented a nice veth set-up and tear-down code in your cake script), that really is only needed because a) iptables/nftables have a friendlier interface than tc, and for ingress tc has no idea about internal IP addresses...

So I only have little game playinggoing on, but I certainly do VC while the rest of the users play and stream, and guess what fully acceptable vide calls and VoIP without playing fancy prioritization games. Yes, I understand that will not work for everybody and sometimes judicious up- or down-priorisation can help, but it is far from a strikt requirement for acceptable low-latency networking.

Yes and no, yes I have not tested qosify, no I know what it offers (and hence what I am "missing"). I get along in my network without it just fine, thank you very much. But knowing what I know, I simply avoid things like using a torrent host simultaneously for interactive work... (or rather when I start torrent clients I limit their number of connections and/or rate). If any other user does not act as carefully, their prerogative, but the fall-out from that decision will be mainly restricted to their computer, IMHO fair enough.

I will do no such thing, sorry. IMHO the thing that qosify is missing is a way to define internal/external IP & port combinations, as I pontificated already, prioritization is a zero sum game and should be targeted as precisely as possible, so being able to limit up-prioritosation not to all receivers of UDP-portX packets but to UDP-portX packets to/from internal IP v.w.x.y helps in that regard.

Well, as I said, you can just write tc filter rules that work on the raw ingress packets just as well, and you always could. This by the way is not intended as criticism of qosify (which I agree is a great package) but of you putting on your "fan-appreciation-for-qosify" a bit to thick for my taste and too much in my face. Tune it down a notch, please. Thanks

EDIT: That last sentence is gold, but I should have followed my own advice there a bit more closely.


Sorry for grump posting, I think @elan's recommendation to try qosify and accept that since changing the ISP's remapping behavior is unlikely to suceed, local DSCP remapping seems the best way forward here.


This thread got a little off topic didn’t it!

OP - the short answer is no.

You cannot force your ISP to stop remapping DSCP. If this was possible it would be massively open to abuse as everyone would simply try to force their traffic as highest priority to try and get the best performance against all the other customers.

It is possible to get your ISP to agree to stop remapping DSCP but this is typically only possible on business/carrier grade connections, where there will be reciprocal agreements between the companies to respect DSCP and govern the amount of ‘high priority’ traffic on the network. Even in this situation, any organisation found abusing this to send, for example, standard browsing traffic tagged as high priority voice traffic would be penalised or cut off.


hi everybody @nbd can you add the lan functionality I only have the traffic for the source port example call of duty 3074 but not the destination which is the following in udp 30000:45000, this seems to me very important because the packets will not transit smoothly otherwise,

Do you doubt how to know which queue is competing?