Shaping in parent policy

[Konstantin Petrovskiy]

Hello everyone!

I have a question about order/fairness of shaping's drops in hierarchical (also known as "nested") qos policy.

For example, we have following nested policy:

interface FastEthernet0/0

service-policy output SHAPE

!

policy-map QOS

      class CLASS1

           bandwidth remaining percent 99

      class CLASS2

           priority 1000

!

policy-map SHAPE

     class class-default

          shape average 10000000

          service-policy QOS

A little bit of calculations:

1. A refference bandwidth that will be used for child policy's calculations - is 10000000Bps = 10000Kbps

2. Class CLASS2 will get as specified 1000Kbps

3. Class CLASS1 will get 99% from (10000Kbps - 1000Kbps) = 8910Kbps

4. Child's policy class class-default will get remaining (10000Kbps - 1000Kbps - 8910Kbps) = 90Kbps

Imagine a situation when 11000Kbps of traffic goes to CLASS1 (excessive) and 500Kbps goes to priority CLASS2 (not excessive). Parent's shaper must then start to drop excessive traffic (11000Kbps+500Kbps)-10000Kbps=1500Kbps.

In other words as I can guess all mixed (CLASS1 & CLASS2) traffic goes to the parent's shaper. Shaper in turn then starts to drop those mixed packets including class that not exceeded its guaranteed bandwidth (it's CLASS2).

My questions are:

1. Does parent's shaper will drop packets with "tail drop" or it will use some other algorithm?

2. Does priority class's CLASS2 traffic will also be affected?

Thanks in advance and have a nice day!

------

Regards, Konstantin.

[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

The ways it's supposed to work, QoS, in your child policy, should function much like if that policy was attached to an interface for the shaped rate.

If traffic rate is under whatever the capacity of an interface or shaper, it just egresses.

However if traffic rate exceed capacity of an interface or shaper, packets are queued, up until queues overflow, then packets are dropped.

Packets that have been queued, are dequeued at the capacity of the interface or shaper.  How they are dequeued depends on your dequeuing policy.  In your case, any packets in class 2, your LLQ, will be dequeued first.  Also with LLQ, packets being placed in the LLQ will be policed at the specified rate.

You non-LLQ classes are dequeued in ratios of their assigned bandwidths.  In your example, it's unclear what the bandwidth allocation would be for class-default.  One would assume it's (the unassigned) 1% of the remaining bandwidth.  If so, class 1 would dequeue 99x faster than class-default.

Each class would drop packets if its (individual) class queue overflows.

[Konstantin Petrovskiy]

Hello Joseph.

Thanks for your reply.

However if traffic rate exceed capacity of an interface or shaper,  packets are queued, up until queues overflow, then packets are dropped.

As I know scheduler takes packets from the queues and place it into tx-ring when tx-ring has free space (we can configure it with tx-ring-limit command), otherwise queues starts to fill in.

Do you mean that shaping in the parent level somehow emulate and suppress packets to shaper rate in tx-ring?

Do you know any details regarding technical realization? I can't find detailed explanation. Only one hint I found here:

[...]
In other words, it is possible that the primary-level policer could drop packets in one class in favor of the other class. This situation would happen because the primary-level policer had enough tokens when the packets for one class arrived, but there were not enough tokens left for the other class. This pattern could continue indefinitely, based on the arrival pattern of the packets.

http://www.cisco.com/en/US/docs/ios-xml/ios/qos_plcshp/configuration/12-4/qos-plcshp-mod-cli-tlhp.html

[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

Taking your last first, it is discussing policing.  Basically they are saying a parent policer will police without regard of child policy classes, which makes sense.  Unsure, whether that helps your understanding as you were using shaping at the parent level.

A shaper will "clock" traffic before it gets to the tx-ring.  In some respects, a shaper is acting like the tx-ring.  I.e. if the transmission rate is under the shaped value, the shaper will pass the packet, just as the tx-ring will pass packets to the interface; neither should queue.  When the transmission rate exceeds the interface's bandwidth, or the shaper's bandwidth, packets are queued.  For the physical interfaces, packets are first queued within the tx-ring, for the shaper, packets are queued to the shaper's queue or queues.

If a shaper is set less than the physical bandwidth (as it usually is - rather pointless if not), it will "meter" out its queued packets at the shaped rate, similar to a physical interface "metering" out its tx-ring queue.

What a shaper is attempting to do, is emulate (over time) an interface of the same bandwidth.

I'm unsure this answers your question.  If not, try to clarify what is confusing you.

[Konstantin Petrovskiy]

Joseph,

still not clear for me how that aggregated shaper works. I mean shaper in class-default that

combine all child's traffic.

It's important for me to understand not "how generally shaping works" but how that aggregated shaper performs buffering or drops. I'm trying to understand - does classes that was not exceeded its own bandwidths are also affected due to shaping?

When the transmission rate exceeds the interface's bandwidth, or the shaper's bandwidth, packets are queued. 

You wrote that packets are queued. It's also correct to say that packets then will be dropped when shaper's queues are fully filled. The question is - which traffic will be exposed to drop?

Also not clear at which stage that shaper are applied. I guess it should meter all volume of traffic after passing a child policies and then...if speed (token bucket etc.) is too much...buffer and drop (for example), but the same question here - which traffic? Fairly between child's classes? Or tail? May be somehow else?

Sorry if I not clarify enough.

[Joseph W. Doherty]

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

I think I understand what your asking - now if I can only explain  . . .

Again, the parent policy's shaper is, more or less, taking the place of the physical interface.  If traffic passing through the shaper is less than the shaper's "bandwidth" it doesn't queue.  Also again, as traffic that doesn't consume all of an interface's physical bandwidth doesn't queue.

When traffic bandwidth utilization exceeds the shaper's bandwidth, again, like a physical interface the excess will be queued.  Also again, like a physical interface how the traffic is actually queued, what might be dropped, how it's dequeued is determined by the (child) policy attached to the shaper.

You ask what traffic will be dropped, well that depends on what kind of queues and policy is defined.  The child policy could have multiple classes, and depending on the IOS version, there might be single FIFO per class or FQ per class, they might have WRED applied to the class, they might have different queue lengths defined per class.  So, as packet are queued, per class, the class configuration will determine what packets will be dropped.  Again, very much like if the (child) policy was applied directly to a physical interface.

In other words, given:

policy-map Sample

class real-time

priority percent 30

class foregound

bandwidth remaining 81

fair-queue

class background

bandwidth remaining 1

fair-queue

class class-default

bandwidth remaining 9

fair-queue

policy-map Shape10M

class class-default

shape average 10000000

service-policy Sample

interface Ethernet0

service-policy output Sample

interface FastEtherent0

service-policy output Shape10M

What happens to your packets, egressing Ethernet0 or FastEthernet0 is, more or less, alike.  Both will average a transmission rate of 10 Mbps, both will queue bursts above 10 Mbps, also more or less, alike.  I.e. given the same traffic, egress behavior will be, more or less, alike.  (NB: I keep writing more or less, because shapers deal with average transmission rates, not physical transmission rates, and I believe shapers often don't account for L2 overhead, but I don't want to distract from the concept that the shaper takes the place of the physical interface.)

[Konstantin Petrovskiy]

Joseph,

thank you very much for such a detailed answer.

Now I think I'm starting to realize how it works. At least I'm trying..

Could you please correct me if I'm wrong in following conclusions:

1) The aggregated shaper works after scheduling of the traffic. It seems this scheme was confused me, because it looks like shaping here performed before scheduling:

2) Scheduller consults not load of the tx-ring but load of the shaper.

3) In turn the situation that I've described at my first post cannot be, because weights in CBWFQ works like a ratios (proportional coefficients). For example (simplified): transmit 1Mbits within second from CLASS2 then transmit 8,91Mbits from CLASS1 within second etc. If CLASS2 occupy not all bandwidth, the ratios tuned accordingly (free bandwidth goes to the CLASS1), but total bandwidth at the output from the scheduler can't exceed 100% of specified bandwidth (10Mbps).

The procedure of proportional partition/sharing works also like a limiter of total bandwith because we have not only relative values but also absolute value at CLASS2.

For example,

CLASS1 = 99% of free bandwidth that equal to 99% of 90% = 89,1% of total

CLASS2 = 10% of total that also can't exceed 1Mbps.

class-default = 0,9% of total

Because of CLASS2 is limited to some absolute bandwidth, each other also limited. Because each other have related to CLASS2 bandwidths. Right?

interface FastEthernet0/0

service-policy output SHAPE

!

policy-map QOS

      class CLASS1

           bandwidth remaining percent 99

      class CLASS2

           priority 1000

!

policy-map SHAPE

     class class-default

          shape average 10000000

          service-policy QOS

P.s.Very  strange for me that Cisco can't describe all aspects of the algorithm  intelligibly and in details. Especially confusing documentation that was  created prior to HQF.

Thanks for your help!

[Joseph W. Doherty]

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

No, not quite right just yet.

In your diagram, notice the "shaper" is after matching packets and before the egress queuing policy.  Also notice the diagram, for traffic the shaper is processing, only forwards traffic, to the egress policy, at the "Configured Rate".

Perhaps another way to think of this, imagine you have two routers in series.  The first router's link to the second is an Ethernet link, the second router's next link interface is FastEthernet.  You attach your QOS policy to the first router's Ethernet interface.

Your first router's policy doesn't consider the second router's FE inteface (which is taking the place of the "Transmit Queue" and "Output Hardware" in the diagram).

The diagram's "Token Bucket", part of the diagram, would be the first router's Ethernet interface, which will only allow a "Configured Rate" of 10 Mbps.

If the ingress traffic to the first router is under 10 Mbps, the policy applied on the first router's Ethernet interface should not see any queued packets, so it doesn't apply.  However, if the ingress rate exceeds 10 Mbps, packets will be pushed into the first router's policy queues.  Into which queues they are placed, how they might be dropped, how they are dequeued from those queues, all depends on the (your QOS) applied policy, not the shaper or the next router's FE interface.

If you can imagine what I've just described, you'll should start to understand how the shaper works, which is much like a virtual interface of some bandwidth.

To further address your questions:

#1 yes, the shaper is performed before egress queuing.  You write this confuses you, which is why I'm suggesting the two router example, above.

#2 Correct.  The shaper determines whether packets will be queued, it also determines when packets are dequeued.  (Again, when dealing with physical interface, too much bandwidth consumption pushes packets into queues.  When an interface is ready to transmit, it will dequeue queued packets, which packet gets dequeued depends on contents of queues, queue policies and what other packets have been dequeued recently.  Also again, shaper does similar, i.e. it determines new ingress packets need to be queued and also determines when to transmit again.)

#3 is mostly correct.  LLQ does not limit other classes, only its own classes.  Yes packets being queued to CLASS2 are rate limited but any unused LLQ bandwidth is available to other classes.  I.e. CLASS1 or your class-default could both use up to the shaper's 10 Mbps.

If there was no CLASS2 traffic, and CLASS1 was only using 4 Mbps, then class-default could use 6 Mbps.  However if CLASS1 wanted 6 Mbps and so did class-default, they would proportion available bandwidth in the ratio 99:1.

[Konstantin Petrovskiy]

Joseph, my last 2 questions:

- is it correct that physically CBFWQing performs several times in accoring to levels of hierarchy? If hierarchy consists of two levels, first of all child policy is performed CBWFQing with its shapers if specified. Next step parent policy is used and its also invoke CBFWQing with its shaper if specified. I'm trying to realize physical model all of that.

- do you have some detailed articles to clear up last misunderstandings?

[Konstantin Petrovskiy]

Found some details at cisco.com:

The router executes the child policy and then the parent policy. However, if the child policy contains policing with a specified drop policy, the router polices and drops the appropriate traffic at the child level, but does not execute the parent policy on the dropped packets. 
The router executes the child policy and then the parent policy. As the packets pass through the router's forwarding engine, the router applies the QoS actions specified in the child policy. After child processing completes, the packets are fed back through the forwarding engine and the router applies the parent policy actions to the aggregate traffic. The router executes the parent policy only on the packets that are fed back. If the router dropped some packets during child processing (the child policy contained a drop policy), the router does not execute the parent policy on those dropped packets. 

[Joseph W. Doherty]

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

Here too the description is of child policer.

Class policers and shapers apply to any traffic that matches the class.

Egress class queuing depends on the need to queue packets for the class, not just matching the class

I can see where the two are confusing because of when they take effect.

[Joseph W. Doherty]

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 child policy (QOS) doesn't have shapers, so your child policy only applies when your parent's shaper pushes traffic to the child policy.

[Konstantin Petrovskiy]

A little bit more pictures that I found

---

---

[Konstantin Petrovskiy]

Joseph,

want to say thank you for your help. I very appreciate that.

[paul driver]

Guys

Just like to say excellent discussion

Res
Paul

Sent from Cisco Technical Support iPad App