few question about DSCP

[chinpohpang851]

Question:

1. how it calculates the decimal value from dscp value? For example clearly 101 x= 4 

2. how packets is mark with DSCP value? I can see that extended ACL is used to match ip precedence value but how the packet mark at first? is it from the end device ? for example, if VOIP device it will automatically mark the dscp value?

[Seb Rupik]

Hi there,

The DSCP value is a 6 bit binary value (taken from the 8 bit TOS field). The decimal value is a simple binary conversion.

Regarding marking, as a rule of thumb you should not trust the QoS markings from devices at the edge of the network as they may try to use markings which expedite their traffic above all others. You should define class-maps to match traffic, policy-maps to define behaviours and then apply it to interfaces via service polices. It is perfectly safe to trust QoS markings between your network devices on their trunk links.

cheers,

Seb.

[chinpohpang851]

1. Now I got it. I separated the first 3 and last 3 bits and do the conversion, that's why its wrong.

2. So what you mean is lets say a application Citrix will have their DSCP bit marked in the packet before sending out and we can modified that in router? I want to know that application services live voice, streaming software will modified the DSCP field automatically with their own preferred value?

[Seb Rupik]

I don't know the specifics for Citrix, but as a rule of thumb don't trust the markings that are received on the access ports at the edge of your network.

A good network QoS policy should be aware of all the traffic types/ classes on the network, have knowledge of SLAs/ expected performance characteristics and create the necessary configuration based on that.

Don't rely on the end devices to behave nicely with all the other devices, at the end of the day they will want their own traffic prioritised above all others!!

[Joseph W. Doherty · Accepted solution]

#2 Yes, i.e. generally a router can modify a ToS value to whatever it desires. It can also leave it as is, with, or without, validation. Again, applications generally can set the ToS to whatever they want; also again, the application may support the setting via some configuration option.

BTW, realize generally by default, network devices don't care what the ToS value is. If they do, often you want to insure values are being used as they should be.

For example, if you define your network devices to provide priority to DSCP EF marked traffic (often used for VolP bearer), you might implicitly trust ToS received from a VoIP phone, while setting all ToS to DSCP BE received from PCs. However, if your PCs supported "soft" VoIP phones, then (ideally as Seb notes) you would want to "analyze" traffic received from a PC, and if it "looked like" VoIP traffic, you could allow DSCP EF to be accepted.

[Joseph W. Doherty]

#1 The DSCP value is the first (left most) six bits of the an IP packet's ToS byte. Your table 6-1 shows the binary and decimal values. When working with the ToS value, take its value and divide by four to obtain the DSCP value, or, conversely, multiply the DSCP value by four to obtain the ToS value. BTW, the first three bits were previously defined as IP precedence. For backward compatibility, the first three bits of DSCP are often used the same way, especially for IP precedence values zero, six and seven. One major exception is if the DSCP is being used for scavenger traffic.

#2 By anything that has the capability to set a ToS value. Applications might set the ToS value. Transit network device might set or change the ToS value. VoIP applications often do initially set a value. They also sometimes offer a configuration option whether to set the value or not and/or what to set the value to. They might also use different values for VoIP bearer vs. VoIP control traffic.