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

[isslam]

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

[lleachii]

• 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?

@isslam

is there a way to avoid DSCP remapping by isp or ceratin route

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

@isslam

is there a tool that can show me where dscp remapping occur

???

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:)

@isslam

i noticed something when i changed tos value from vps to tos 1 i received ping packet with my router with tos 1 and 2 received with 2 3 with 3 4 with 0 and 5 with 1 so for every 4 tos value they reset to 0, 1, 2, 3 so is this qos classfication of my isp ? and when i changed dscp to any value i always receive 0x0 tos value is there explaination to that ?

As I noted:

@lleachii

(Perhaps you should explain why you are researching tagged packets.)

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

[isslam]

i want to setup cake qos correctly with dscp

[lleachii]

@isslam

want to setup cake qos correctly with dscp

OK, cool!

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

Then I'm sure we all can help.

[isslam]

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

[lleachii]

@isslam

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

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???

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

[anomeome]

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

[lleachii]

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).

@elan

I recommend that you read ALL the posts in these threads and use Qosify

That is a good suggestion for the OP.

[moeller0]

@elan

I recommend that you read ALL the posts in these threads and use Qosify because it is better and in both solutions you don't need SQM at all:

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.

[anomeome]

Sure appears to be a veth there for me.

[moeller0]

@elan

but if you are actually using that host, the torrent will still hog that host's bandwidth.

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.

@elan

knowledge of what you are doing

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).

@elan

If the the torrents and other such hogs could be relegated to the bulk tin, then that host will see a vast improvement in all other traffic types.

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.

@elan

To solve this problem you need a Veth interface, iptables rules, knowledge of what you are doing, etc, but with Qosify you only need to add a simple port + DSCP mark and only that, nothing more.

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...

@elan

Qosify is a simple but powerful definitive solution to a BIG problem than SQM had and it benefits people who play games or do video conferencing.

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.

@elan

As you said in previous posts, that you never tested Qosify, so this means you don't know what you are missing.

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.

@elan

As I said before, implement the LAN IP Address priority option (ask the developer @nbd to implement this feature).

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.

@elan

Qosify is based on eBPF (which is better than iptables or nftables and you don't need to create a Veth interface to tag download traffic).

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.

[moeller0]

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.

[supersebbo]

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.

[anon78773196]

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,

[edwpat]

@moeller0

the prioritized flows start to compete with each other

Do you doubt how to know which queue is competing?