DSCP markings and QoS treatment

pweinhold · ‎01-09-2012

Hi,

I'm designing a QoS implementation and I'm going to use class-maps and policy-maps and service-policy commands. Now, obviously you use these commands to classify different kinds of traffic and define how you want it handled. But I'm confused about the degree to which certain DSCP markings, by themselves or by default, do or do not result in a certain kind of treatment by routers.

For example, I was reading Cisco's document on DSCP values and they said this about the Assured Forwarding class:

"Assured Forwarding PHB guarantees a certain amount of bandwidth to an AF class and allows access to extra bandwidth, if available."

So if I use clas-maps to define a certain kind of traffic as AF41, but don't configure any other treatment with a policy-map, will the router give that traffic some kind of preferential treatment just because I've marked it as AF41?

I'd have the same question about the EF class.

But at the same time, some classes, such as the CS classes (CS1, CS2, etc.) are comlpetely arbitrary - just labels, essentially - and you define whatever treatment you want, correct?

I guess I'm having trouble differentiating between QoS treatment that I would explicitely configure and QoS treatment that routers will automatically perform, by default, based on certain DSCP values.

Thanks.

Joseph W. Doherty · ‎01-09-2012

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

The only router QoS configuration that I recall that by default treats traffic differently based on ToS byte (IP Precedence) is WFQ which is the default on E1 and slower serial interfaces. Otherwise, you need to configure QoS. Most such configured QoS also doesn't by default, treat traffic differently based on ToS byte either except for WRED, and FQ in class-default CBWFQ prior to HQF variant.

On L3 switches that support features that look at the ToS byte, they will in a default enabled QoS configuration treat packets differently too although they also generally by default don't trust the ToS byte and will reset it when QoS is enabled.

In other words, for the most part, pure default device configurations usually don't provide any special treatment of the ToS but as noted above, there is an exception on routers. Usually you need to enable QoS features, and if you do, you might get some new default special processing of ToS.

lgijssel · ‎01-09-2012

Like Joseph says, there is no default behavior. You can (must) configure a router to perform qos-controlled forwarding.

While doing this, you, the operator can configure it to perform different kinds of forwarding for any of the 64 dscp values available. Alternatively you can also use an acl to recognize traffic for this purpose.

What we often do is configure a certain amount of bandwidth for priority-class traffic (most often voice)

Another option is to reserve a certain amount of bandwidth for a special type of traffic. (video, citrix, ..)

Such traffic is then generally recognized by its dscp value.

The only things which are fixed are: the (1) dscp values 0-63 and (2) the types of forwarding a device can provide.

The latter is depending on both hard- and software capabilities of the device but you can configure every forwarding behavior for each of the dscp values available. You could for example give highest priority to unmarked (CS0) traffic if you wanted. Not very useful of course but nevertheless possible.

One more thing: qos processing is a per-hop behavior. This means that each node or device in the network must be specifically configured to run qos according to the defined policy.

regards,

Leo

pweinhold · ‎01-09-2012

Well, here's an example that maybe frames my question a little bit better:

Suppose I want to define three classes of traffic - one for voice, one for VTC and one for streaming video. In order of priority, I want the voice traffic to have the highest priority, followed by the VTC traffic, then followed by streaming video traffic. I understand that voice traffic should be marked as EF and I can use the priority command to ensure that it gets put in a queue ahead of all other traffic. But how would I handle the VTC and streaming video traffic? How could I configure QoS so that VTC gets put in a secondary queue and streaming video gets put in a tertiery queue? Could I mark VTC as AF41 and streaming video as AF42 - would that have any effect by itself? And if I do that, would I configure anything else under my policy map?

Here's an example of how my policy map would look. Note the question marks - what would I configure to establish secondary and tertiary queues for VTC and streaming video?

policy-map QOS_QUEUE_EGRESS

class VOICE

priority percent 20

class VTC_AF41

???

class STREAMING_VIDEO_AF42

???

Joseph W. Doherty · ‎01-09-2012

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Well as Leo noted, you can really use any markings you desired although the recommendation is usually to prioritize DSCP values, more or less, in the same way IP Precedence was. For example something AF4x is usually more "important" than something AF2x. (The reason for such a recommendation is in case you do cross a device just looking at the DSCP as IP Precedence.)

Further on the need, or lack there of, of ToS DSCP markings, you can implement QoS policies without looking or using the ToS bye at all. ToS markings real purpose is to allow follow on devices to easily and quickly determine the QoS service needs of such marked packets.

How you prioritize other classes in CBWFQ isn't by absolute priorities, like used by the LLQ of CBWFQ or PQ, but by allocation of sufficient bandwidth to meets the needs of the traffic. For example you might, if your streaming video needed 1 Mbps, set bandwidth to 1 Mbps or on later IOS versions the equivalent percentage of bandwidth (e.g. 2/3 of a T1).

If you really want to do a secondary and tertiary queues, and prioritize as such, you could set the tertiary queue to a minimum bandwidth allocation and the secondary to all the other bandwidth not being used by LLQ.

Further answers to your questions:

But how would I handle the VTC and streaming video traffic?

Depends on their service needs. Streaming video often has different service needs for live vs. non-live streams.

How could I configure QoS so that VTC gets put in a secondary queue and streaming video gets put in a tertiery queue?

In CBWFQ, the policy map would have a class for each, as you've done in your second post.

Could I mark VTC as AF41 and streaming video as AF42 - would that have any effect by itself?

Yes, you could mark that way and no, unless you configure to treat differently. Even WFQ will treat alike since them both map into the same IP Prec value.

And if I do that, would I configure anything else under my policy map?

Again, depends on service needs. Bandwidth statement sets proportion of bandwidth allocation, but other statements might be needed too, such as changing queue size allocation.

Here's an example of how my policy map would look. Note the question marks - what would I configure to establish secondary and tertiary queues for VTC and streaming video?

Queues would be defined by the classes. How the queues are treated depends on the configuration statements used within the class and between classes.

lgijssel · ‎01-09-2012


policy-map QOS_QUEUE_EGRESS
 class VOICE
  priority percent 20
 class VTC_AF41
  ???
class STREAMING_VIDEO_AF42
  ???

The complete policy-map could look like this:

policy-map QOS_QUEUE_EGRESS

class VOICE

priority percent 20

class VTC_AF41

bandwidth percent 20

class STREAMING_VIDEO_AF42

bandwidth percent 30
class class-default

bandwidth percent 30

random-detect dscp-based

Be careful when assigning bandwidth to the priority queue. Beyond a certain level, the remaining queues may become "starved of bandwidth" resulting in not be able to send their traffic. I would say that 20% is about the maximum you should assign to it.

regards,

Leo

Joseph W. Doherty · ‎01-10-2012

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

To the original poster, Leo's example is a fine example of how an egress policy might be structured, but some points to keep in mind include: the bandwidth percentages shown in his posting might not serve your needs as we don't know the traffic bandwidth needs nor the link capacity, actual available syntax varies per IOS version (i.e. bandwidth percentage wasn't available in earlier versions of IOS supporting CBWFQ, I believe), I normally advise against using random-detect (WRED) unless you really understand the technology.

pweinhold · ‎01-11-2012

Thanks for the good feedback. I've got a couple follow-up questions:

Joseph says that, without any configured treatment, a router will treat packets marked with AF41 and AF42 equally. But don't the different AF classes specify different drop probabilities? So wouldn't packets in AF42 be more likely to be dropped, even if you don't configure any specific queuing treatment?

Also, in Leo's sample config, he recommends defining a default class and using random-detect dscp-based. The random-detect command enables WRED based on DSCP markings, but what are those DSCP markings? By definition, isn't the default class comprised of traffic that isn't specifically marked with a DSCP value?

Thanks.

lgijssel · ‎01-11-2012

 By definition, isn't the default class comprised of traffic that isn't specifically marked with a DSCP value?

The default class is actually all traffic which has not been defined in one of the other class maps.

From itself, the router has no understanding of the significance of the dscp values.

It will only give preferential treatment if it is told to do so.

When using WRED, the router uses a preconfigured table defing the drop probablities for every dscp value which is not defined in another part of the policy. Example: if you only have a priority class for voice (EF) this traffic will get the assigned bandwidth in the priority queue. All other traffic will be subject to WRED, the W stands for Weighted and the weight is determind by the dscp value. The assigned values can be changed but by default af41 is rated more important than af42 and so on. You can see the preconfigured values when looking at the output from sh policy map.

regards,

Leo

Joseph W. Doherty · ‎01-11-2012

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

But don't the different AF classes specify different drop probabilities?

That's the RFC recommendation.

So wouldn't packets in AF42 be more likely to be dropped, even if you don't configure any specific queuing treatment?

Not by default.

The random-detect command enables WRED based on DSCP markings, but what are those DSCP markings?

As Leo's posting notes, random-detect dscp-based will show you all the markings used by default. I think it's all the even values, from 0..63, or just AFxy values, CS values and a few others like BE and EF, but it might vary per platform. NB: if you just use random-detect, IP Prec values are used.

By definition, isn't the default class comprised of traffic that isn't specifically marked with a DSCP value?

No, as Leo also has in his post, it's any unmatched traffic for that policy. Class maps don't need to use the ToS byte at all. For example, you can match on an ACL or NBAR.

e.g.

class-map Important match-any

match protocol http

match protocol telnet

class-map Unimportant match-any

match protocol ftp

policy-map QoS_Egress

class Important

bandwidth percent 50

class Unimportant

bandwidth percent 10

class class-default

bandwidth percent 40