any ideas on what dscp class that have the highest and lowest priority ?
You need to ask your ISP if they prioritize DSCP/TOS tagged traffic, and if so how. It also depends on all ISPs along the path that will carry the packet.
(Perhaps you should explain why you are researching tagged packets.)
I'm sure your ISP would be upset if you did prioritize your traffic (beyond normal - e.g. they use a tag for VoIP and you use that for all packets) and they utilize tags in their network. Be careful.
3 Likes
i think they don't use dscp tag as tcpdump shows traffic with dscp 0x0
DSCPs are really just markers in IP packets that allow you to use 64 different labels. What you do with these labels is your thing. There are IETF RFC that describe specific per hob behaviours (PHBs) and propose a specific DSCP value to mark packets for such treatment, but just marking a packet will not assure that it is treated any specific way.
So the answer is, it depends on how you configured your prioritization system.
This generally is unlikely to be robust and reliable, though there are studies that shpw depending on which specific DSCP pattern and which path there can be up to an 80% chance of a DSCP making it from end 2 end unchanged (but the end points can not really figure out whether a received DSCP was set by the other end or somewhere along the path).
No, your ISP will tend to do either of two things:
a) remap all incoming packets to safe/appropriate DSCPs (if you are lucky your ISP will only re-map those DSCPs the he uses inside its own prioritization set-up and will leave all others unchanged)
b) drop packets with DSCPs the ISP is not willing to accept from other networks (often CS7 is used for network control and an ISP might courteously drop CS7 packets to help its peers not leaking control packets, but most likely such packets will just be re-mapped to DSCP0 on ingress).
DSCPs are really only valid inside what is called a diffserve domain, so a network or interconnected networks that agreed to use certain PHBs and to use spcific DSCP values to steer packets to receive the desired PHB. Diffserve domains typically and by default at the edge of a network, so your ISP will not treat your home network as part of its diffserve domain and hence ignore most DSCPs. That said, some ISPs will tolerate/allow a small set of specific DSCPs to actually have some meaning, e.g. some ISPs allow EF/VA markings on VoIP packets to allow for prioritization of upstream VoIP packets (typically only for VoIP offerings of that specific ISP as far as I understand). If this looks like a mess then this is because this evolved organically and was never designed without some legacy issues that needed to be handled gracefully, so IMHO it is less messy and more complicated 
.
Yes, that is quite common that ISPs simply re-map all packets to the default value of zero, but not all ISPs do that and and end user typically has a hard time to decide whether a sender simply only sent DSCP0 packets in the first place or whether the ISPs or some other entity on the network path changed the setting.
1 Like
Yes, there are multiple topics in this forum on that issue, some I believe you participated in in the past. The current hottest approach is qosify.
But please keep in mind that prioritization mostly is a zero sum game, that is for every packet that is treated preferentially another packets is treated worse, which logically implies that you need to be careful to only up-prioritize relative few packets. In the extreme if you put all packets into the highest priority tier the effect is identical to not prioritize any of them.
3 Likes
I'm going on the history of the OP (and possible nation). Editing these "hidden" values in packets can be against communications laws in some nations...a good reason they don't like some folks playing with "open" routers. As you know in most nations with "freeer" Internet, the ISPs handle the packets as received and modify as they desire excepting some "net neutrality" regulations or lack thereof (especially in places with bring-your-own-device rights, i.e. FCC-land, albeit close sourced drivers prevent that sometimes on certain technologies).
Sure, if it's new equipment. Those values have other meanings in old routers.
No, you don't control their router, so remarking the outbound tags may do nothing except cost you more CPUs.
1 Like
IP's DSCP field is not hidden... possible that some countries disallow changing it (not a lawyer not prepared to sink time in researching this) but I severely doubt it. The mechanisms you would need to control this so you can enforce the law can effortlessly be used to simply remedy the issue by re-mapping it and quite some applications already set DSCPs by default, that cat is out of the bag.
All true, but rather orthogonal to DSCPs IMHO.
Yes and no, before 6bit diffserve (DS) + 2 bit ECN there was 8bit Type of Service (TOS) which was used similarly to the 6bit DS field to allow marking for differential treatment of packets, re-mapping was already used for the TOS field, so different but similar.
Yes, you can (probably) easily set a specific DSCP value on outbound packets, but you ISP will likely not treat them in any meaning-full way different from DSCP0 marked packets (unless you have a cobntract clause where the ISP promises special treatment for specific marking, possible, but rare and apparently often only available for commercial internet access for an extra cost).
1 Like
Same thing...but in some nations, the government is the ISP...hence the "orthogonal" issue.
Hence my advice is simply don't touch it.
I've also seen the tag used to signal alarms, automated processes, etc. A common case may be to route the packet use a more expensive (but faster) Internet connection. 
Again, some programs already set DSCPs outside of direct user control. I have a hard time believing that outside of extremes like north korea any government would punish thing that irrelevant and outside of endusers control... DSCPs are fair game to change any government ISP that wants to assert control over them will do so by re-mapping them. If you have ecplict counter examples of countries where folks are allowed to access the internet at all, but where DSCPs are off-limits, please share them, but acting on the vage possibility that a country might disallow this seems a bit to subservient to me (and I am German, so if this seems to much subservience for me... 
)
I never said such a thing....
I noted the most common use case I know, which is to reroute traffic over e.g. fiber instead of satellite or vice versa.
"Punish" may not be the word in that case, but I'm sure if an ISP noticed one customer suddenly carrying all traffic over their most expensive connection, they'd fix it in a hurry.
You simply adhered to the theory that marking may do nothing, my theory is it may do something. That's all....after all, I assume the OP want's to change the tag for something to happen, right? 
So...in my thinking, it was kinda odd to think on the path that nothing could happen, lol.
As I recall, the OP never really answered what they expected to happen...and as you confirm, the tag has to be handled with priority along the entire path, not just the OP's ISP. So, yea, all cool! 
@isslam , to be clear, you can change the tag with an iptables rule...I'm looking for an example...but, I've tried it before it does nothing and sometimes caused issues. I leave it now all cases to what the device transmitted.
1 Like
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 ?
This is to be expected, since diffserv was introduced the lowest two TOS bits (that carry the values 0/1, 0/2 respectively so cover the TOS values 0, 1, 2, 3) are used for ECN signaling, and ISPs tend to honor that so remapping is not going to affect the 8bit TOS field in the IP header but only the 6bit DSCP field in the header, the consequence of that is if you actually set the lower 2 TOS bits these will likely survive re-mapping through your ISP (or any other network/AS on the path).
As an example TOS 255 is 1 1 1 1 1 1 1 1 (here low to high) that is all 8 bits set to one (1+2+4+8+16+32+64+128) = 255, if you remap the upper 6 DSCP bits to zero you get 1 1 0 0 0 0 0 0 or (1+2+0+0+0+0+0+0) = 3, so in essence all that survives of your TOS bit are what ever bit-pattern "lived" in the lowest two bits you set.
And IIUC that is the pattern you observed?
Changed where exactly?
2 Likes
when i changed DSCP with iptables from vps for example iptables -t mangle -A POSTROUTING -j DSCP --set-dscp 63 i always gets from my router (the receiving destination) with tcpdump
15:21:24.567145 IP (tos 0x0, ttl 39, id 32746, offset 0, flags [DF], proto ICMP (1), length 84)
156.182.182.35 > 197.37.75.132: ICMP echo request, id 57505, seq 6, length 64
if i changed 63 to any value i gets the same tos value (0x0)
This is also expected, some entity on the path (likely your ISP) re-maps all DSCPs to zero, which many ISPs commonly do. If you set DSCP decimal 63 and do not also enable ECN the bit pattern you send will look like (low to high):
0 0 1 1 1 1 1 1: (0+0+4+8+16+32+64+128) = TOS 252 = (0+0+1+2+4+8+16+32) = DSCP 63
then the DSCP bits get re-mapped (apparently to zero) and you get:
0 0 0 0 0 0 0 0: (0+0+0+0+0+0+0+0) = TOS 0 = (0+0+0+0+0+0+0+0) = DSCP 0
so far nothing unusual let alone nefarious here...
So in the context of the post above setting DSCPs leaves the low two TOS bits to be set by the ECN code in the kernel but apparently you did not enable outgoing ECN on your VPS.
i am not technical professional 
but yeath that i observed and you suggest to benefit from my isp is to set tos to 1 ?
No, if you want to use the two ECN bits all you can use them for really is ECN, as any AQM on the network is allowed and expected to change either 1 or 2 to a 3 if they detect congestion (instead of simply dropping a packet). So manually setting TOS decimal 1 is great for testing but useless for real traffic, sorry.
The IETF has a wealth of RFCs that explain DSCP and fiffserv in ample detail, maybe you want to spend some time reading there....
3 Likes