QOS Hierarrchical Shaping

[eandrcisco007]

Could somebody explain what would be the overall reason that we see lots of drops under both class-default parent policy and class-default child policy?! Considering the fact that the overall bandwidth utilization has been low.

(It goes up to 155Mbps max out of 200Mbps available BW but why it doesn't use the remaining of the available BW up to 200Mbps and why it keeps dropping too many packrats under class-default?)

I have configured a shaper under parent policy.

policy-map ISP-parent
 class class-default
  shape average 190000000
   service-policy child

Below is the child policy.

policy-map child
 class gold_classmap
  priority percent 15
  set ip dscp cs5
 class silver_classmap
  bandwidth remaining percent 50
  set ip dscp af31
 class bronze_classmap
  bandwidth remaining percent 35
  set ip dscp af21
 class gold_classmap_phones
  priority percent 20
  set ip dscp ef
 class qos-criticaldata
  set dscp cs3
  bandwidth remaining percent 15
 class class-default
  set ip dscp af11

Any idea/feedback?

Thank you.

[paul driver · Accepted solution]

Hello

I cannot comment on why your dropping packets, But I can see you have shaping enabled upto 190mb on that interface, So even if you have a 200mb pipe, Your shaping will only allow upto 190mb and any continuous bursting over that value wont be allowed.

It could be that traffic is getting dropped by your ISP.for not correctly making to their defined qos policy's, Or that just to much traffic is saturating your link?
The nested child classes take the bandwidth from the defined parent shape value, And you have specified around 30mb of that for LLQ, with the rest being weighted to the other child classes.

As for the class default, its best effort traffic, And my understanding of this class is that its FIFO queuing by default  As such it doesn't provide any fairness to all of the packets in that class pertaining to any remaining BW because whatever arrives first gets serviced first, However applying WFQ would provide some fairness to all of the BE traffic.

Possible suggestion is:
1) Try decreasing the tc interval to the shaping, Doing should decrease the waiting on the shaped packets for the next time interval (tc) to initiate and allow them to exit the interface faster.

Tc set to 0.125ms
shape average 190000000 23750000

Tc set to 10ms
shape average 190000000 1900000 

2) Apply some fair queuing and congestion avoidance to the class-default class
policy-map child
class class-default
fair-queue
random-detect dscp-based

res
Paul

[Joseph W. Doherty · Accepted solution]

2) Apply some fair queuing and congestion avoidance to the class-default class
policy-map child
class class-default
fair-queue
random-detect dscp-based

I would recommend not to use WRED with FQ.  (Actually I also recommend not to use WRED at all unless you're a QoS expert.)

[eandrcisco007]

Thank you Paul, I am going to start with fair-queuing and .... and provided contents are spot on.

[Joseph W. Doherty]

If you have enough traffic to congest your shaper, one common issue, your queues might not be sufficiently sized for BDP to support 200 Mbps. 

Another possible issue, your traffic just doesn't have enough bandwidth.  Often a high drop rate will cause lower than expected utilization, as TCP flows keep cycling their bandwidth consumption.  If that's the case, with TCP, you can work on better drop management to maximize your "goodput".  Often FQ, as suggested by Paul, can help here, as it avoids class tail-drop that concurrently impact multiple flows.  Also FQ tends to drop from the bandwidth "hogs" first.  (NB: WRED can also be used to better manage drops, but again, I believe it requires an expert to "tune it".  [BTW, WRED can also be used to configure drop tiers, which isn't as difficult to "get right" as using it for RED.])

[eandrcisco007]

Great details, Thank you very much... I am going to work on it based on your feedback.