Understanding QoS

[shikamarunara]

Hi everyone,

     I am preparing to implement QoS in our environment.  For our circumstances, because the subject of QoS can be pretty vast, I've decided to break down the default auto QoS sytax generated on a 3750 and change it as needed.  I understand much of it, but have always kind of found COS to DSCP mappings confusing and hopefully someone can help me understand it better.

     Here is the default COS syntax generated on 3750 for auto qos;

mls qos map policed-dscp  24 26 46 to 0

mls qos map cos-dscp 0 8 16 24 32 46 48 56

mls qos srr-queue input bandwidth 90 10

mls qos srr-queue input threshold 1 8 16

mls qos srr-queue input threshold 2 34 66

mls qos srr-queue input buffers 67 33

mls qos srr-queue input cos-map queue 1 threshold 2  1

mls qos srr-queue input cos-map queue 1 threshold 3  0

mls qos srr-queue input cos-map queue 2 threshold 1  2

mls qos srr-queue input cos-map queue 2 threshold 2  4 6 7

mls qos srr-queue input cos-map queue 2 threshold 3  3 5

mls qos srr-queue input dscp-map queue 1 threshold 2  9 10 11 12 13 14 15

mls qos srr-queue input dscp-map queue 1 threshold 3  0 1 2 3 4 5 6 7

mls qos srr-queue input dscp-map queue 1 threshold 3  32

mls qos srr-queue input dscp-map queue 2 threshold 1  16 17 18 19 20 21 22 23

mls qos srr-queue input dscp-map queue 2 threshold 2  33 34 35 36 37 38 39 48

mls qos srr-queue input dscp-map queue 2 threshold 2  49 50 51 52 53 54 55 56

mls qos srr-queue input dscp-map queue 2 threshold 2  57 58 59 60 61 62 63

mls qos srr-queue input dscp-map queue 2 threshold 3  24 25 26 27 28 29 30 31

mls qos srr-queue input dscp-map queue 2 threshold 3  40 41 42 43 44 45 46 47

mls qos srr-queue output cos-map queue 1 threshold 3  5

mls qos srr-queue output cos-map queue 2 threshold 3  3 6 7

mls qos srr-queue output cos-map queue 3 threshold 3  2 4

mls qos srr-queue output cos-map queue 4 threshold 2  1

mls qos srr-queue output cos-map queue 4 threshold 3  0

mls qos srr-queue output dscp-map queue 1 threshold 3  40 41 42 43 44 45 46 47

mls qos srr-queue output dscp-map queue 2 threshold 3  24 25 26 27 28 29 30 31

mls qos srr-queue output dscp-map queue 2 threshold 3  48 49 50 51 52 53 54 55

mls qos srr-queue output dscp-map queue 2 threshold 3  56 57 58 59 60 61 62 63

mls qos srr-queue output dscp-map queue 3 threshold 3  16 17 18 19 20 21 22 23

mls qos srr-queue output dscp-map queue 3 threshold 3  32 33 34 35 36 37 38 39

mls qos srr-queue output dscp-map queue 4 threshold 1  8

mls qos srr-queue output dscp-map queue 4 threshold 2  9 10 11 12 13 14 15

mls qos srr-queue output dscp-map queue 4 threshold 3  0 1 2 3 4 5 6 7

mls qos queue-set output 1 threshold 1 138 138 92 138

mls qos queue-set output 1 threshold 2 138 138 92 400

mls qos queue-set output 1 threshold 3 36 77 100 318

mls qos queue-set output 1 threshold 4 20 50 67 400

mls qos queue-set output 2 threshold 1 149 149 100 149

mls qos queue-set output 2 threshold 2 118 118 100 235

mls qos queue-set output 2 threshold 3 41 68 100 272

mls qos queue-set output 2 threshold 4 42 72 100 242

mls qos queue-set output 1 buffers 10 10 26 54

mls qos queue-set output 2 buffers 16 6 17 61

mls qos  

My question is in the first two lines;

mls qos map policed-dscp  24 26 46 to 0

mls qos map cos-dscp 0 8 16 24 32 46 48 56

The first line, seems to me, to be saying that traffic marked as CS3, AF31, and EF will be set to the IP Precedence value of 0.  However, according to what I've read, this is not a very high priority;

PCP	Network priority	Acronym	Traffic characteristics
1	0 (lowest)	BK	Background
0	1	BE	Best Effort
2	2	EE	Excellent Effort
3	3	CA	Critical Applications
4	4	VI	Video, < 100 ms latency
5	5	VO	Voice, < 10 ms latency
6	6	IC	Internetwork Control
7	7 (highest)	NC	Network Control

Am I misunderstanding this?

[Aileron88 · Accepted solution]

As far as I'm aware you are correct, this is saying to police these values down to this level but this is ONLY if you are performing policing & your exceed action is to reference this 'policed-dscp' qos map.

It would be worth having a read of this:

http://www.cisco.com/en/US/products/hw/switches/ps5023/products_tech_note09186a0080883f9e.shtml#concept232

Thanks,

Adam

[Joseph W. Doherty · Accepted solution]

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

You're understanding is correct.  As Adam described, those are DSCP conversion values if using a policing statement to "mark down" traffic that's oversubscribed.  In other words, for example, for DSCP marked packets initially marked with 24, 26 or 46, if they were "too fast" (per a mark down policer), they would be remarked to just DSCP 0.  The conversion table defaults to same markings, so a packet with 22 would be "remarked" to 22.

The purpose of doing this is to deprioritize their priority because such packets were out-of-profile.  So for example an out-of-profile VoIP packet would be deprioritized and treated as any other BE packets.  This doesn't have to be done, it's optional.  Also for "too fast" packets, another option might be to drop the packet.  Lastly, if you leave the packet with the same marking, the policer's stats can be used to let you know you have traffic exceeding expected transmission rate.

You didn't ask further about you confusion on the CoS statement, but what that does is map (convert) each of the CoS values to a DSCP value.  What it appears to be doing is converting each CoS value to the corresponding DSCP class selector value except for CoS 5 which is converted to DSCP EF (46).

[shikamarunara]

The reasoning of policing the VoIP packets in such a way is vexxing.  In a constraing situation, it seems to me that the most important packets would be the router/network's own traffic (handled with PAK priority - routing protocols, etc), then call control and RTP.  Why would Cisco add a policing statement in its auto QoS baseline stating that if there's a contraint that RTP and call control be marked down to Best Effort?  Maybe I'm missing something.

[Joseph W. Doherty · Accepted solution]

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

Cisco AutoQoS didn't, at least in what you posted, add a policing statement, they modified the default mark down map.

When working with real-time vs. routing control, what's most important is debatable.  If a routing update is telling this router about some distance network becoming reachable or not, what's more important, keeping VoIP quality high or getting the routing update a few milliseconds sooner?  Generally, we can wait a little on the routing information.

However, getting the routing update is very important, so we don't want 100% VoIP traffic to stave bandwidth such that the routing update isn't received, so we police the VoIP traffic to stay within the expected bounds.  (NB: on routers running CBWFQ with VoIP in LLQ, there's an implicit policer that drops all traffic in the LLQ beyond what's expected [when there's congestion].)  We also place routing updates in the highest non-priority class.

[shikamarunara]

Thank, Joseph, I appreciate the input.