Few questions regarding QOS

ahmed.negm · ‎01-18-2014

Hello All, I do really need a help on understanding some points on QOS. Given the below configuration

---------

R1#sh run policy-map COS-OUT-SHAPED-Gi0/0.15

Building configuration...

Current configuration : 124 bytes

!

policy-map COS-OUT-SHAPED-Gi0/0.15

class class-default

shape average 6000000

service-policy COS-OUT-Gi0/0.15

!

end

R1#sh run policy-map COS-OUT-Gi0/0.15

Building configuration...

Current configuration : 454 bytes

!

policy-map COS-OUT-Gi0/0.15

class DSCP-OUT-RT <<<<<<<< Voice class

priority 2448 307000

police 2456000 307000 307000 conform-action set-dscp-transmit 46 exceed-action drop violate-action drop

class DSCP-OUT-D1

bandwidth remaining percent 60

random-detect dscp-based aggregate

random-detect exponential-weighting-constant 9

random-detect dscp values 26 minimum-thresh 39 maximum-thresh 117 mark-prob 20

random-detect dscp values 28 minimum-thresh 19 maximum-thresh 38 mark-prob 20

service-policy COS-OUT-D1-Gi0/0.15 <<<< Those are just remarking service-policy so no big deal

class DSCP-OUT-D2

bandwidth remaining percent 30

random-detect dscp-based aggregate

random-detect exponential-weighting-constant 9

random-detect dscp values 18 minimum-thresh 61 maximum-thresh 122 mark-prob 20

random-detect dscp values 20 minimum-thresh 34 maximum-thresh 68 mark-prob 20

service-policy COS-OUT-D2-Gi0/0.15

class DSCP-OUT-D3

bandwidth remaining percent 9

random-detect dscp-based aggregate

random-detect exponential-weighting-constant 9

random-detect dscp values 10 minimum-thresh 78 maximum-thresh 156 mark-prob 20

random-detect dscp values 12 minimum-thresh 51 maximum-thresh 102 mark-prob 20

service-policy COS-OUT-D3-Gi0/0.15

!

end

-----------

Now my questions

1 - If customer is sending Data traffic with rate over 6 Mg will voice traffic be impacted or not ?

2 - Given the WRED parameters above or any other WRED just the concept , now if let's say D3 starts sending traffic with rate above 9 % of bandwidth Cisco allows it to be granted more bandwidth if there are available bandwidth in the other classes ... so my question is when will WRED mechanism gets triggered and starts dropping random packets ... or also in other words minimum-thresh 78 .. The number 78 what's this number exactly a function of.

Vasilii Mikhailovskii · ‎01-18-2014

Hello.

Could you please provide sh policy-map int ... out to see exact values applied per class?

My concern is "priority 2448 307000" (why do you need this burst size?) and "shape average 6000000" without bc value (could lead to longTc, as a result voice could be delayed -> jitter).

In general:

1) Voice won't be impacted unless it's trying to consume more than 2.4M

2) minimum-threshold is about mean queue length, as far as packets are leaving the queue fast enough and mean queue length does not reach min-threshold (and queue size if big enough), WRED won't affect traffic flow.

mean/average queue length is calculated as:

$http://upload.wikimedia.org/math/f/7/8/f78b99c3acdfd943b83065ffc323b6ca.png$

o - is old (previous calculation) mean value;

c - current queue size;

n - exponential weight.

ahmed.negm · ‎01-18-2014

Hello Mikhailovsky, Thanks alot for your feedback ... below is the output of the show policy-map interface command.

Now the point in our scenario here for voice class

Shaping Tc = 4 msec ? and that during congestion can hold voice packets long enough in the shaping queue to be delayed .. I also agree that Tc = 1 second for voice is pretty high

R1#show policy-map interface GigabitEthernet0/0.15 out

GigabitEthernet0/0.15

Service-policy output: COS-OUT-SHAPED-Gi0/0.15

Class-map: class-default (match-any)

1092335700 packets, 164159193029 bytes

30 second offered rate 109000 bps, drop rate 0 bps

Match: any

Queueing

queue limit 64 packets

(queue depth/total drops/no-buffer drops) 0/443958/0

(pkts output/bytes output) 1091892062/163408460116

shape (average) cir 6000000, bc 24000, be 24000

target shape rate 6000000

Service-policy : COS-OUT-Gi0/0.15

queue stats for all priority classes:

queue limit 64 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 681873638/53435643102

Class-map: DSCP-OUT-RT (match-any)

681873638 packets, 53432399602 bytes

30 second offered rate 64000 bps, drop rate 0 bps

Match: access-group name DSCP-OUT-RT

23864233 packets, 1916592950 bytes

30 second rate 0 bps

Match: ip dscp ef (46)

658009382 packets, 51515804418 bytes

30 second rate 64000 bps

Priority: 2448 kbps, burst bytes 307000, b/w exceed drops: 0

police:

cir 2456000 bps, bc 307000 bytes, be 307000 bytes

conformed 681873642 packets, 53435645360 bytes; actions:

set-dscp-transmit ef

exceeded 0 packets, 0 bytes; actions:

drop

violated 0 packets, 0 bytes; actions:

drop

conformed 64000 bps, exceed 0 bps, violate 0 bps

Class-map: DSCP-OUT-D1 (match-any)

18992406 packets, 3318131662 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: ip dscp af31 (26)

18992405 packets, 3318131662 bytes

30 second rate 0 bps

Match: ip dscp af32 (28)

0 packets, 0 bytes

30 second rate 0 bps

Queueing

queue limit 64 packets

(queue depth/total drops/no-buffer drops) 0/2797/0

(pkts output/bytes output) 18989609/3314687455

bandwidth remaining 60% (2131 kbps)

Service-policy : COS-OUT-D1-Gi0/0.15

Class-map: DSCP-OUT-D1INP (match-all)

18988005 packets, 3317788384 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: not access-group name DSCP-OUT-SAA

Match: ip dscp af31 (26)

police:

cir 2136000 bps, bc 267000 bytes, be 267000 bytes

conformed 18950041 packets, 3264424529 bytes; actions:

transmit

exceeded 8188 packets, 11423065 bytes; actions:

set-dscp-transmit af32

violated 29776 packets, 41940790 bytes; actions:

set-dscp-transmit af32

conformed 0 bps, exceed 0 bps, violate 0 bps

Class-map: class-default (match-any)

4401 packets, 343278 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: any

Class-map: DSCP-OUT-D2 (match-any)

8350015 packets, 9847058982 bytes

30 second offered rate 13000 bps, drop rate 0 bps

Match: ip dscp af21 (18)

8350015 packets, 9847058982 bytes

30 second rate 13000 bps

Match: ip dscp af22 (20)

0 packets, 0 bytes

30 second rate 0 bps

Queueing

queue limit 64 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 8350015/9614261592

bandwidth remaining 30% (1065 kbps)

Service-policy : COS-OUT-D2-Gi0/0.15

Class-map: DSCP-OUT-D2INP (match-all)

8349659 packets, 9847029098 bytes

30 second offered rate 13000 bps, drop rate 0 bps

Match: not access-group name DSCP-OUT-SAA

Match: ip dscp af21 (18)

police:

cir 1072000 bps, bc 134000 bytes, be 134000 bytes

conformed 8346224 packets, 9609038478 bytes; actions:

transmit

exceeded 1783 packets, 2692330 bytes; actions:

set-dscp-transmit af22

violated 1652 packets, 2494520 bytes; actions:

set-dscp-transmit af22

conformed 13000 bps, exceed 0 bps, violate 0 bps

Class-map: class-default (match-any)

356 packets, 29884 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: any

Class-map: DSCP-OUT-D3 (match-any)

228837546 packets, 85332347392 bytes

30 second offered rate 9000 bps, drop rate 0 bps

Match: ip dscp af11 (10)

228837207 packets, 85332100294 bytes

30 second rate 9000 bps

Match: ip dscp af12 (12)

339 packets, 247036 bytes

30 second rate 0 bps

Queueing

queue limit 64 packets

(queue depth/total drops/no-buffer drops) 0/440737/0

(pkts output/bytes output) 228396809/84798625289

bandwidth remaining 9% (319 kbps)

Service-policy : COS-OUT-D3-Gi0/0.15

Class-map: DSCP-OUT-D3INP (match-all)

225991869 packets, 85098183768 bytes

30 second offered rate 8000 bps, drop rate 0 bps

Match: not access-group name DSCP-OUT-SAA

Match: ip dscp af11 (10)

police:

cir 320000 bps, bc 40000 bytes, be 40000 bytes

conformed 190569143 packets, 35751650461 bytes; actions:

transmit

exceeded 1607999 packets, 2160593173 bytes; actions:

set-dscp-transmit af12

violated 33814727 packets, 47185940134 bytes; actions:

set-dscp-transmit af12

conformed 8000 bps, exceed 0 bps, violate 0 bps

Class-map: class-default (match-any)

2845677 packets, 234163624 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: any

Class-map: class-default (match-any)

154282420 packets, 12229309004 bytes

30 second offered rate 21000 bps, drop rate 0 bps

Match: any

queue limit 64 packets

(queue depth/total drops/no-buffer drops) 0/424/0

(pkts output/bytes output) 154281997/12245241200

Vasilii Mikhailovskii · ‎01-18-2014

Hello.

I guess 4ms for parent class is good; I would say that even 10ms is good.

I would say that 307,000 bytes for bc is a really high value. Not sure why is it in use... it might be some logic behind?!!

But it says, that on the link of 6M voice could solely allocate whole link for 400 ms and then send no traffic for 600 ms! I'm not sure that you are expecting such a behavior!

I think, that for voice class, Tc could be about 20 ms.

Not sure why do you need be for policer, if exceed action is drop (monitoring?)

abpsoft · ‎01-18-2014

MikhailovskyVV wrote:

Not sure why do you need be for policer, if exceed action is drop (monitoring?)

I don't see why there's a policer in DSCP-OUT-RT in the first place. It can never match (priority is already policing the excess traffic). If it's there to just force the DSCP to EF, wouldn't it be more readable to use a set statement? Unless, of course, I know nothing about the hardware platform and this is black magic which performs better on certain metal^Wsilicon.

Confused,

Andre.

Joseph W. Doherty · ‎01-18-2014

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

abpsoft wrote:

MikhailovskyVV wrote:
Not sure why do you need be for policer, if exceed action is drop (monitoring?)

I don't see why there's a policer in DSCP-OUT-RT in the first place. It can never match (priority is already policing the excess traffic). If it's there to just force the DSCP to EF, wouldn't it be more readable to use a set statement? Unless, of course, I know nothing about the hardware platform and this is black magic which performs better on certain metal^Wsilicon.

Confused,

Andre.

Actually, on many platforms the implicit policer only polices against packets being queued in the LLQ, not just passing through the LLQ class.

ahmed.negm · ‎01-19-2014

I believe the main role of the policer is to avoid voice packets from exceeding their bandwidth even if the other classes for data are empty.... Am not sure why was it configured to have priority also performing bandwidth restrictions while it's already there in the policing command.

My main question was by any mean could data traffic cause packet drops to voice if user is bursting very large chunk of data traffic ... by theory this should never happen ... i want to confirm the theory part am i correct on this ... or in other words can the shapping buffer get full and start dropping packets regardless if they're voice or not ?

Joseph W. Doherty · ‎01-19-2014

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

In theory, data volume shouldn't ever be adverse to VoIP, with your policy construct. But, in practice, it may. (I read your OP as you were asking about "real world".)

Vasilii Mikhailovskii · ‎01-18-2014

Hello, Ahmed.

What is the platform/IOS you are using (sh ver)?

@abpsoft, "priority" will drop traffic in case of congestion, but will send in other case. So, "priority" is not allowing to limit maximum bandwidth - that is why we need policer.

abpsoft · ‎01-19-2014

MikhailovskyVV wrote:

@abpsoft, "priority" will drop traffic in case of congestion, but will send in other case. So, "priority" is not allowing to limit maximum bandwidth - that is why we need policer.

Ah yep. Joseph and Ahmed stated the same. I remembered that wrongly - I was under the impression that priority comes with a built-in hard dropping policer. But it's just a starvation protector in that it will drop only during congestion and otherwise just pass traffic (without ensuring LLQ). In the words of the docs:

In addition, the priority command implements a maximum bandwidth guarantee. Internally, the priority queue uses a token bucket that measures the offered load and ensures that the traffic stream conforms to the configured rate. Only traffic that conforms to the token bucket is guaranteed low latency. Any excess traffic is sent if the link is not congested or is dropped if the link is congested.

Thanks for clearing my confusion and sorry for the sidetracking,

Andre.

Joseph W. Doherty · ‎01-18-2014

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

#1 "It depends"

on such as:

Why are you shaping? (I.e. what's downstream that you're shaping for?)

Is the send 6 Mbps at L2 or L3, and which is the shaper counting?

What is the Bc/Tc, and does that matter (which it often does for VoIP)?

What's the tx-ring fifo queue set to?

Does the shaper manage any queues other than the child policy's?

Is the IOS implemenation working correctly?

#2 WRED looks as a moving average of number of packets in queue when it's about to add another packet to queue. If adding the packet, places the moving average into the min..max or greater than max ranges, then WRED does its "thing". (Since WRED uses moving averages, in theory, in could tail drop a new packet even though the queue is physically empty or not consider it for drop even though actually queue depth is way beyond max.

ahmed.negm · ‎01-19-2014

Hello Joseph,

I just want to really understand this for the WRED part ... consider for instance i had bandwidth command on D3 class set that D3 queue gets bandwidth 3 Mb/s and the whole link bandwidth is 10 Mb/s ... what happens if the link is clear and no other data classes are sending traffic , as Cisco say this class can take bandwidth from other classes ... in my practical experience i get to see the case where the class D3 sends up to 7 Mb/s or even more with no WRED drops and sometimes you get it sending at 4 Mb/s and getting drops....

So how does the WRED knows the total link utilization and how does it calculate the queue size itself to determine it's threshold

Thanks alot for your previous reply

Joseph W. Doherty · ‎01-19-2014

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

In answer to your question about no drops at 7 Mbps but drops at 4 Mbps, that's because WRED is tracking queue depths down at the millisecond level and your "7 Mbps" or "4 Mbps" is over what time interval?

Basically, microsbursts can lead to drops while longer term bandwidth utilization shows far from 100% utilization. If fact, if there's enough microburst dropping, the drops may drive down the average bandwidth utilization. (BTW, in theory, with straight FIFO, you can have no drops at 100% utilization, while at a 1% utilization have a 99% drop rate. [I normally don't rant on the subject, how useless measuring bandwidth utilization, alone, is.])

JohnTylerPearce · ‎01-19-2014

BTW, in theory, with straight FIFO, you can have no drops at 100% utilization, while at a 1% utilization have a 99% drop rate. [I normally don't rant on the subject, how useless measuring bandwidth utilization, alone, is.])

Joseph, sorry to sound stupid, I'm having trouble understanding this. That at microbursts, could you possible explain this further?

Thanks in advance, I really appreciate it.

Joseph W. Doherty · ‎01-19-2014

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

John, question is not stupid.

What I think you're asking about, bandwidth vs drops, isn't related to microbursts.

Imagine a router with only two interfaces, same bandwidth. As ingress bandwidth cannot exceed egress bandwidth, 100% in would be 100% out, i.e. no queuing on egress. So, we show 100% bandwidth utilization, but that's bad, right?

Now imagine a switch with 100 (10 Mbps) Ethernet interfaces and with one 10g Ethernet interface. Further imagine the 10g interface only has a queue/buffer of 1. Lastly, imagine a frame/packet arrives on all 100 Ethenet intefaces at the same time. (Not likely in real world, but concept is important.) 10g interface can only buffer 1 frame/packet, everything else is discarded. So, we show, on 10g interface, only 1% bandwidth utilization, so that's good, right?