QoS - Deprioritize traffic

Routing & Switching SD-WAN
1

Hello all,

I have a project to implement small QoS scenario into my network backbone.

This scenario would mainly consists to deprioritize an identified traffic on ingress interface on edge router.

By deprioritize, I mean that, in case of congestion, all this identified traffic, can (and have to) be discard instead of all other traffic

I checked the possibility to class and remark this traffic with specific DSCP value but that implies to remark all others traffic with another higher DSCP value.

Recently, I noticed a class of service called “Scavenger” (DSCP CS1) allowing, in my understanding, traffic remarked with this value to be assign the lowest configurable queuing service. (less than best-effort services)

Is anyone already used this kind of CoS ?

More generally, which best QoS implementation could be achieve my use case to deprioritize a type of traffic only ?

Here is a schema illustrating the backbone and, indicated by red arrows, where come from the traffic to deprioritize :

Screenshot from 2022-10-17 16-05-49
Screenshot from 2022-10-17 16-05-49788Ă—653 58.6 KB

Thanks to you,
Trif’

2

Hello Trif

First of all, we must remember that QoS has several distinct operations. One is classification and marking, which has to do with identifying certain types of traffic and setting or changing their DSCP values, while the other is employing QoS mechanisms that act upon those markings (queuing, shaping, policing etc…). Note at this point we’re talking only about Layer 3 QoS which involves the ToS field of the IP header.

An excellent description of how this works is found in RFC2475 and I’ve included the diagram below:

                           +-------+
                           |       |-------------------+
                    +----->| Meter |                   |
                    |      |       |--+                |
                    |      +-------+  |                |
                    |                 V                V
              +------------+      +--------+      +---------+
              |            |      |        |      | Shaper/ |
packets =====>| Classifier |=====>| Marker |=====>| Dropper |=====>
              |            |      |        |      |         |
              +------------+      +--------+      +---------+

Fig. 1: Logical View of a Packet Classifier and Traffic Conditioner

Let’s ignore the “Meter” for now. Packets will be classified, marked accordingly, and then either shaped or dropped depending upon various set conditions.

Now as far as the interpretation of those markings goes, there are specific predefined approaches, which are further described in the IP Precedence and DSCP Values lesson. Various DSCP values are associated with specific traffic types and default treatment of those types, but keep in mind that you can change that behavior to whatever you like. There are specific definitions to commonly used DSCP values, but you don’t necessary have to use those, you can change them and create your own.

So if you want to achieve what you describe, simply mark the packets you want with a particular DSCP value that is not being used, such as CS1 for example (which corresponds to a binary value of 001000). Once you mark your traffic, you can then create the policy you want to drop those packets.

But you must be aware, many devices have default settings for how to deal with specific DSCP markings as far as QoS goes. Be sure that the value you choose is not being used anywhere else in your network, and that the default behavior of your specific routers is not acting upon that particular value in an unwanted way.

In theory, you can have up to 64 different traffic classes since the DSCP field is composed of six bits. However, QoS RFCs recommend but do not require, specific values and encodings to be used, and that is why we have various definitions such as DF, EF, AF, and CS. But ultimately, you as a network admin have full flexibility to define traffic classes as you see fit, so you have the power to override the default behaviors.

I hope this helps you in your specific design and answers your questions about the CS1 DSCP value. If you have any further questions, or get stuck along the way, let us know!

I hope this has been helpful!

Laz

1 Like
3

Hello @lagapidis,

Thanks for your answer and for all the clarifications about QoS mechanisms.
I have a better understanding to how it works :slight_smile:

So, as I understand it, to get a trafic to be deprioritised, I have to mark it to a specific DSCP value and use a policy which apply a drop priority higher than the default class where belong all others traffic ?

Most of the QoS sample configuration show policy examples using bandwith reservation but I don’t think my current use case require such a thing.
I don’t see any parameter that might specify, for example, the drop priority.

I was wondering if a simple parameter to set priority exists to a Class of Service ?

I checked the QOS feature “Multi-Level Priority Queue” in order to achieve this but there is only 2 priority level available :

R4(config-cmap)#policy-map test
R4(config-pmap)#class test
R4(config-pmap-c)#priority ?
<1-100000000> Kilo Bits per second
level Multi-Level Priority Queue
percent % of total bandwidth

R4(config-pmap-c)#priority level ?
<1-2> Multi-Level Priority Queue

Not knowing to which priority level is assigned the default traffic I cant be sure of the behavior if i set the lowest priority level to the policy map of the deprioritized traffic

Thanks again for your support !
Trif’

4

Hello Trif

In order to drop traffic you must use policing. You can create several class maps that match particular DSCP values, and then you can choose to have them transmitted when they conform to the policing rate, or dropped when they don’t conform. You can find out more information about policing at this lesson:

Some policing configurations that will help you to craft your own set of QoS mechanisms to achieve your goal can be found here:

Let us know how you get along!

I hope this has been helpful!

Laz