QOS police vs bandwidth - is this configuration wrong?

[SJ K]

Hi all,

I understand bandwidth in QOS is use to guarantee a minimum bandwidth

I understand police in QOS is to set a limit to the maximum bandwidth.

class test_out
  police 1608000 50000 100000 conform-action set-dscp-transmit af31 exceed-action set-dscp-transmit af32 violate-action set-dscp-transmit 28
  bandwidth 2542
  random-detect dscp-based
  random-detect exponential-weighting-constant 7
  random-detect dscp 26 50 80 10
  random-detect dscp 28 15 40 5

Is this a single-rate 3 color configuration ?

Can someone tell me if the above configuration is self defeating ?

I have a guarantee bandwidth of 2542Kb, but traffic is being police at 1608000 bits = 1570Kb

Regards,

Noob

[Georg Pauwen]

Hello,

since you are not dropping anything (exceed and violate actions simply assign a lower DSCP value, rather than dropping the traffic), you are not reallly limiting the traffic. What do you want to achieve ?

That said, if possible, it is better to shape traffic. Policing pretty much cuts off traffic when the limit is exceeded, whereas shaping smoothes the packet output rate...

[SJ K]

Hi Georg,

Thank you and appreciate your reply.  The config is actually inherited from an existing configuration.
I am trying to make sense if

a) having a policer with a lower CIR (1570kb) then the configured minimum bandwidth (2542kb), am i still able to attain the bandwidth specified ?  
-- i believe i am able to hit the minimum guarantee because exceed and violate action does drop any packets at all;  am i right ?

b) looking at the exceed and violate action, one mark as AF32 and another mark with DSCP28  - isn't AF32 = DSCP28 ?
What's the different then ?

c) Can i also say for the below configurations

i) police  50000 1000 2000
vs
ii) police 20000 1000 2000

i) has a faster bucket refill rate then ii) ?

Regards,

Noob

[Georg Pauwen · Accepted solution]

Hello,

all your assumptions are correct. I cannot say anything about why your inherited configuration is the way it is, but AF32 indeed equals DSCP28, and the configured policer effectively puts no limit on the amount of traffic. If there is anything else configured, such as other policer or shapers, it could make sense, if other traffic is marked with values higher than DSCP28/AF32...

The bucket refill rate for the first policer is indeed higher, since your cir is higher than in the second one (50000 vs 20000)...

[SJ K]

Hi Georg,

Appreciate your confirmation and input.

policy-map test_policy
 class test_mgmt
  police 8000 8000 8000 conform-action set-prec-transmit 6 exceed-action set-prec-transmit 6 violate-action set-prec-transmit 6
  bandwidth 36
  random-detect
  random-detect exponential-weighting-constant 3
  random-detect precedence 0 20 32 10
  random-detect precedence 6 20 32 10
 class test_ef
  police 664000 2000 2000 conform-action set-dscp-transmit ef exceed-action drop  violate-action drop
  priority 664 2000
 class test_out
  police 1608000 50000 100000 conform-action set-dscp-transmit af31 exceed-action set-dscp-transmit af32 violate-action set-dscp-transmit 28
  bandwidth 2542
  random-detect dscp-based
  random-detect exponential-weighting-constant 7
  random-detect dscp 26 50 80 10
  random-detect dscp 28 15 40 5
  queue-limit 256 packets
 class class-default
  bandwidth 282
  random-detect
  random-detect exponential-weighting-constant 4
  random-detect precedence 0 12 32 5
  random-detect precedence 1 12 32 5
  random-detect precedence 2 12 32 5
  random-detect precedence 3 12 32 5
  random-detect precedence 4 12 32 5
  random-detect precedence 5 12 32 5
  random-detect precedence 6 40 64 10
  random-detect precedence 7 12 32 5
  queue-limit 96 packets
policy-map test_overall
 class class-default
  shape average 3560000 35600
  service-policy test_policy

---

---

Indeed there are a separate class in the policy-map for priority handling and the entire policy-map is then place into another policy-map for traffic shaping, but does that serve any explanation on

a) why would the author created a policer with a lower bandwidth then the minimum guarantee ? -- sole purpose is to mark down exceeding traffic but still allowing the minimum bandwidth to be reach ?

b) marking the exceeding and violating traffic with the same DSCP value ? (AF32 and DSCP28 ) because the police doesn't allow AF32 to be specify twice in a single command ?

Regards,
Noob

[Joseph W. Doherty]

"i) police 50000 1000 2000
vs
ii) police 20000 1000 2000

i) has a faster bucket refill rate then ii) ?"

On a percentage basis no, on a bits/sec basis, yes.

[Joseph W. Doherty]

"That said, if possible, it is better to shape traffic. Policing pretty much cuts off traffic when the limit is exceeded, whereas shaping smoothes the packet output rate..."

"... better to shape . . ." BTW, not always, as if often the case, it really depends on what you're trying to accomplish. However, in many cases, as engineers don't often really understand policing or shaping, and they often are trying to mimic a lower bandwidth interface, a shaper, especially using its default values, more closely mimics a lower bandwidth interface's behavior.

Also, shapers, though, are often not a feature found on switches and I don't recall them being able to be used for traffic marking.

[Joseph W. Doherty]

"I understand bandwidth in QOS is use to guarantee a minimum bandwidth"

Yes and no. What it really does is set the class's bandwidth ratio relative to other classes. (BTW, I would recommend against using bandwidth values, other than percentages [if supported], as the latter is a bit clearer and doesn't bump in the the issues associated with using the same policy against interfaces with different bandwidths.)

"I understand police in QOS is to set a limit to the maximum bandwidth."

Sometimes, but not always, as your example, by not dropping packets, is used to mark traffic based on bandwidth usage, it doesn't actually limit bandwidth usage.

"Is this a single-rate 3 color configuration ?"

Possibly - I would need to review the definition of a "single-rate 3 color" (also in this case, I believe, DSCP 28 and AF32 are the same value, so only two colors are actually being used - the syntax of the command might require the 3rd value).

"Can someone tell me if the above configuration is self defeating ?"

No, because as noted above (and in Georg's posts), bandwidth isn't actually being capped. However, even if it was, you might want to set a higher priority for dequeuing even though you set a "lower" bandwidth cap. (NB: LLQ's implicit policer is a perfect example.)

[SJ K]

Hi Joseph,

Thank you so much for your input. To be honest.. its abit overwhelming for me... so please do correct me i i don't get you..

Sometimes, but not always, as your example, by not dropping packets, is used to mark traffic based on bandwidth usage, it doesn't actually limit bandwidth usage."

So can i say the author is trying to just mark down exceeding traffic in the that class but still allows traffic from that class to reach the minimum bandwidth specified ?

No, because as noted above (and in Georg's posts), bandwidth isn't actually being capped. However, even if it was, you might want to set a higher priority for dequeuing even though you set a "lower" bandwidth cap. (NB: LLQ's implicit policer is a perfect example.)

Do you mean tat the define "bandwidth" when use in CBWFQ will entitle that particular class to have a higher priority over other class due to the bandwidth weight ?   Are you referring to the policer when you mentioned "set lower bandwidth cap" ?

On a percentage basis no, on a bits/sec basis, yes.

Reason for asking is that

config1)
class_test

bandwidth 4000

police 50000 1000 2000 conform-action set-dscp-transmit af31 exceed-action set-dscp-transmit af32 violate-action set-dscp-transmit 28

VS

config2)
class_test

bandwidth 4000

police 20000 1000 2000 conform-action set-dscp-transmit af31 exceed-action set-dscp-transmit af32 violate-action set-dscp-transmit 28

For the same traffic volume,  can I say config2 will have more traffic being mark down since its CIR is lesser and its token refresh rate is slower per sec (hence less token in bucket = more token exceeding/violating = mark down)

Regards,

Noob

[Joseph W. Doherty]

"So can i say the author is trying to just mark down exceeding traffic in the that class but still allows traffic from that class to reach the minimum bandwidth specified ?"

No, I would say the author appears to be is setting two different ToS markings to allow different drop probabilities within the same class's WRED settings. Notice the higher ToS gets dropped sooner by the WRED configuration.

"Do you mean tat the define "bandwidth" when use in CBWFQ will entitle that particular class to have a higher priority over other class due to the bandwidth weight ?"

Depends what the two classes bandwidth is configured at. Again, the bandwidth statement is what sets the dequeuing priority relative to other bandwidth configured classes. For example

class A
bandwidth 100
class B
bandwidth 200

or

class A
bandwidth 10 percent
class B
bandwidth 20 percent

In either of the above, class A would be dequeued at half the bit rate for class B (assuming they both wanted the bandwidth). In the above, the bandwidth values vs. bandwidth percentages may (likely) generate different absolute dequeuing weights, but, regardless, those values will be in a 1:2 ratio.

"For the same traffic volume, can I say config2 will have more traffic being mark down since its CIR is lesser and its token refresh rate is slower per sec (hence less token in bucket = more token exceeding/violating = mark down)"

Cannot say whether more traffic will be marked down without knowing the actual traffic's bandwidth consumption behavior. For example, what if the traffic was from a T1 or E1?

Normally, of course, you would expect traffic within CIR not to be marked down, and traffic over CIR to be marked down, but CIR is an average consumption over time. What's the average of (5 5 5 5 5 5), (4 5 6 6 5 4) and (1 1 1 9 9 9)? It's five in all cases, however whether it's over CIR, or not, depends on line speed and Bc and Be.

What CIR, alone, should determine, is how fast your bucket is drained. Bc/Be determines the size of your leaky bucket, while you physical bandwidth is the maximum flow rate that fills your bucket.

That aside, what I posted earlier about the two token replenishment rates might need correction. What I had in mind was just a change in CIR rate while assuming you allow the device to default Bc and Be. However, your example only changes the CIR rate while keeping the same Bc and Be.

[SJ K]

Hi Joseph,

Thanks for coming back and sharing with us more insights.

q1) Under CBWFQ, does a class in a policy-map correspond to a single queue ? and WRED define in that class is use to randomly drop packets in that particular queue only - right ?

q2) read from the doc, that a bucket token arrival rate is as below
(time between packets < which is equal to T - T1 > * policer rate)/8 bytes

So by the above calculation -  if the amount of traffic and everything stay constant across the 2 configs earlier with different CIR/policer rate but same bc and be,  tokens refill in config2 will be slower -> when the refill rates are slower , there will be lesser tokens available for usage and thus a higher chance for traffic to exceed the bc bucket - is my understanding right ?

Regards,
Noob

[Joseph W. Doherty · Accepted solution]

Q1

Usually, but not always. All LLQ classes share one queue (except for ASRs, which I believe support two LLQs). WFQ in a class creates multiple queues for that class.

Yes, WRED would only target packets within the class that it's defined within.

Q2

If the leaky bucket is always the same size (i.e. same Bc/Be), and so is the inflow to the bucket the same, a smaller CIR means the leaky bucket drains slower (or in your way of thinking, tokens aren't replenished as quickly), so yes there's a higher probability the bucket will overflow sooner, or more often. Again, though, how traffic is impacted by any policer depends on the nature of the actual traffic vs. the policer's parameters.

[SJ K]

Thank you Joseph.

Lastly, can i just confirm all the DSCP markings are just base on industrial standard; Meaning I can mark a class as low priority but still put it into priority queue on each hop on end2end and it will still be handle as priority ?

Regards,

Noob

[Joseph W. Doherty]

DSCP markings are defined within a RFC. There's no requirement they be honored, so the only way to determine how they will be processed (if processed at all), is by consulting those that control the transit device(s) your traffic will pass across.

Also, transit device may change ToS markings, so again, without consulting those who control transit devices, it's not even guaranteed your marking will survive end-to-end.

Usually, but not always, device configuration don't provide any special processing for different ToS markings, nor change them.

[SJ K]

Hi Joseph,

Appreciate your reply and confirmation.   I hope you don't mind this last question ->

Also, transit device may change ToS markings, so again, without consulting those who control transit devices, it's not even guaranteed your marking will survive end-to-end.

Is it better then to mark all default-class in the CE router with best effort priority (000000) then -> i am worried that some traffic in default-class have got existing markings and causes them to be handle separately (with better priority) on the transit devices further up the link. ?

Regards,

Noob