Hierarchical QoS

[ovt]

Hi!

Could anybody help me understand the following example taken from cisco.com and mentioned there as a "best practice":

class match-any voice

...

class match-any mission-critical

...

! Other classes

policy-map my-policy

class voice

priority percent 20

class mission-critical

priority percent 40

class other

bandwidth ...

class class-default

fair-queue

policy-map my-shaper

class class-default

shape average 256000

service-policy my-policy

interface fa0/0

service-policy output my-shaper

Shaping is used here because not all bandwidth of fa0/0 is available (ISP polices our traffic). Inside the shaper voice and mision-critical classes should have priority treatment.

Unfortunately it simply doesn't work (IOS 12.4(5)). ALL traffic classes are shaped equally. ALL packets (voice, data, etc.) go to the shaper buffers in FIFO order (!), delayed there (!) and then processed by the inner policy-map (my-policy). Policy-map my-shaper has no idea about priorities of classes in the inner policy-map (my-policy). This is not good for voice, to say the least.

Can anybody tell me is this a bug or feature? Are there workarounds?

[pkhatri]

This is how the hierarchical policy works - there are two levels of queueing nbeing performed here:

- the first is the queueing according to the nested policy, my-policy. According to this policy, there will be as many queues as you have defined classes. Now, traffic matching each of these classes will queue up in their respective queues ... The CBWFQ will then de-queue packets from the queues based on how you have configured the classes (either using the priority command or the bandwidth command). Packets from the priority queues will be de-queued before packets from non-priority (except in congestion situations, where they will not be allowed to exceed their configured percentage/bandwidth).

- the output of the first set of queues (as described above) will be fed into the shaping queue defined by your my-shaper policy, which will then leak out packets at a uniform rate of 256000.

So the traffic output you see should be no more than 256k...

Is that what are you seeing ?

Hope that helps - pls rate the post if it does.

Regards,

Paresh.

- the overall output of the policy will be a stream of traffic shaped to 256000

- within this shaped traffic stream, traffic will b

[ovt]

My voice traffic stays within the profile (it is less than 20 percent of the shaper bandwidth = 256K), but it is delayed by the shaper when I open ftp session and send a file. You're probably right about the hierarchical QoS processing, but it doesn't solve my problem: I want to not oversubscribe ISP link, which is 100Mbps, but only 256Kbps is allowed to be sent, *and* at the same time guarantee low delay to voice and mission-critical traffic classes. How should I configure this?

[mheusinger]

Hello,

it´s not a bug but a feature. The shaper in the policy-map my-shaper indeed does not differentiate any traffic - it uses just class class-default.

What it does is to create a "virtual interface with 256 kBit" on a FastEthernet.

The underlying reason, why this makes sense in the scenario given is, that queueing ONLY is involved, when there is an overload situation on an interface. In the example queueing would only be involved, if there is more traffic than 100 Mbps. With 50 Mbps traffic everything would be sent to the ISP router with line speed and HIS router would have to prioritize the traffic on the congested WAN link.

The shaper makes sure we are not overloading the ISP link and allows you to prioritize your traffic within the 256 kbps as you like.

Cool thing really!

Hope this helps!

Regards, Martin

[ovt]

Maybe it's a feature, but looks like a bug :) The problem is that the shaper DOES NOT "create a "virtual interface with 256 kBit" on a FastEthernet". I'll try to explain:

Suppose that instead of fa0/0 we have a serial0/0 with the bandwidth 256K. In this case the shaper is not needed. Policy map my-policy will guarantee 20 percent of the bandwidth to the voice class. The delay is guaranteed (!) to be low for the voice class and it is guaranteed there will be no drops (!) in the voice class if the voice traffic stays within the profile *regardless* of how much *data* traffic is sent. Right?

Now suppose we have a fa0/0 and an ISP which allows us to send only 256K. The shaper is needed to not overload the ISP link. The outcome for voice class is quite different here: voice traffic is delayed (!) by the shaper and drops in the voice class are possible (!) *if* there are many *data* packets to be sent (voice traffic still stays within the profile).

This makes hierarchical QoS totally useless if voice or some other high-priority traffic is present on the link.

Any comments?

[pkhatri]

Hi,

Your description of how this will work is not quite correct. In your example about applying a 256k shaper to the Fa0/0 interface, let's say you configure a voice class with a priority percent of 20%. Now, no matter how much data packet traffic hits this class, your voice packets will always be guaranteed at least 20% of 256k, or 51.2k. If you are intending to submit voice traffic to this policy at a rate greater than 51.2k, then you have obviously configured your policy incorrectly. The voice traffic is delayed by the shaper only because you have decided to shape it out to the ISP, since the ISP will be policing any traffic over the committed rate. If you really want your voice traffic to take priority and use up to 100% of the link, then configure it with a priority percent of 100% (after setting max-reserved-bandwidth to 100% as well).

So I disagree with your statement that hierarchical qos is useless - there are many providers (including ones I support) that use it successfully for voice traffic. Also, typically, you would not want to run voice traffic over a 256k link without using some form of link fragmentation and interleaving !

Hope that helps - pls rate posts that help.

Regards,

Paresh

[ovt]

Even if I configure "priority percent 100" it doesn't solve the problem. Here is an example (very interesting!). ICMP echo is the "priority" class, ftp - is the "data" class:

class-map match-any test

match protocol icmp

match access-group 199

class-map match-any ftp

match access-group 198

!

policy-map inner

class test

priority percent 100

class class-default

fair-queue

policy-map my-policy

class class-default

shape average 32000 16000

service-policy inner

interface FastEthernet0/0

ip address 10.0.0.1 255.255.255.0

service-policy output my-policy

C3725#sh policy-map interface fa0/0

FastEthernet0/0

Service-policy output: my-policy

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

1640 packets, 1788307 bytes

5 minute offered rate 31000 bps, drop rate 0 bps

Match: any

Traffic Shaping

Target/Average Byte Sustain Excess Interval Increment

Rate Limit bits/int bits/int (ms) (bytes)

32000/32000 4000 16000 16000 500 2000

Adapt Queue Packets Bytes Packets Bytes Shaping

Active Depth Delayed Delayed Active

- 20 1620 1762027 1586 1754351 yes

Service-policy : inner

Class-map: test (match-any)

251 packets, 35642 bytes

5 minute offered rate 1000 bps, drop rate 0 bps

Match: protocol icmp

251 packets, 35642 bytes

5 minute rate 1000 bps

Match: access-group 199

0 packets, 0 bytes

5 minute rate 0 bps

Queueing

Strict Priority

Output Queue: Conversation 24

Bandwidth 100 (%)

Bandwidth 32 (kbps) Burst 800 (Bytes)

(pkts matched/bytes matched) 232/32944

(total drops/bytes drops) 0/0

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

1389 packets, 1752665 bytes

5 minute offered rate 30000 bps, drop rate 0 bps

Match: any

Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 16

(total queued/total drops/no-buffer drops) 20/0/0

What is happening with ICMP see in my next message.

[ovt]

Reply from 10.0.0.3: bytes=100 time=1ms TTL=254

Reply from 10.0.0.3: bytes=100 time=1ms TTL=254

Reply from 10.0.0.3: bytes=100 time=499ms TTL=254

Reply from 10.0.0.3: bytes=100 time=497ms TTL=254

Reply from 10.0.0.3: bytes=100 time=495ms TTL=254

Reply from 10.0.0.3: bytes=100 time=493ms TTL=254

Reply from 10.0.0.3: bytes=100 time=491ms TTL=254

Reply from 10.0.0.3: bytes=100 time=489ms TTL=254

Reply from 10.0.0.3: bytes=100 time=475ms TTL=254

Reply from 10.0.0.3: bytes=100 time=473ms TTL=254

Reply from 10.0.0.3: bytes=100 time=471ms TTL=254

Reply from 10.0.0.3: bytes=100 time=469ms TTL=254

Reply from 10.0.0.3: bytes=100 time=467ms TTL=254

Reply from 10.0.0.3: bytes=100 time=465ms TTL=254

Reply from 10.0.0.3: bytes=100 time=463ms TTL=254

Reply from 10.0.0.3: bytes=100 time=461ms TTL=254

Reply from 10.0.0.3: bytes=100 time=459ms TTL=254

Reply from 10.0.0.3: bytes=100 time=447ms TTL=254

Reply from 10.0.0.3: bytes=100 time=445ms TTL=254

Reply from 10.0.0.3: bytes=100 time=443ms TTL=254

Reply from 10.0.0.3: bytes=100 time=441ms TTL=254

Reply from 10.0.0.3: bytes=100 time=439ms TTL=254

Reply from 10.0.0.3: bytes=100 time=456ms TTL=254

Reply from 10.0.0.3: bytes=100 time=454ms TTL=254

Reply from 10.0.0.3: bytes=100 time=452ms TTL=254

Reply from 10.0.0.3: bytes=100 time=451ms TTL=254

Reply from 10.0.0.3: bytes=100 time=449ms TTL=254

Reply from 10.0.0.3: bytes=100 time=447ms TTL=254

Reply from 10.0.0.3: bytes=100 time=445ms TTL=254

Reply from 10.0.0.3: bytes=100 time=206ms TTL=254

Reply from 10.0.0.3: bytes=100 time=204ms TTL=254

Reply from 10.0.0.3: bytes=100 time=202ms TTL=254

Reply from 10.0.0.3: bytes=100 time=201ms TTL=254

Reply from 10.0.0.3: bytes=100 time=199ms TTL=254

Reply from 10.0.0.3: bytes=100 time=197ms TTL=254

Reply from 10.0.0.3: bytes=100 time=195ms TTL=254

Reply from 10.0.0.3: bytes=100 time=193ms TTL=254

Reply from 10.0.0.3: bytes=100 time=191ms TTL=254

Reply from 10.0.0.3: bytes=100 time=189ms TTL=254

...

Reply from 10.0.0.3: bytes=100 time=22ms TTL=254

Reply from 10.0.0.3: bytes=100 time=21ms TTL=254

Reply from 10.0.0.3: bytes=100 time=19ms TTL=254

Reply from 10.0.0.3: bytes=100 time=18ms TTL=254

Reply from 10.0.0.3: bytes=100 time=17ms TTL=254

Reply from 10.0.0.3: bytes=100 time=16ms TTL=254

Reply from 10.0.0.3: bytes=100 time=15ms TTL=254

Reply from 10.0.0.3: bytes=100 time=14ms TTL=254

Reply from 10.0.0.3: bytes=100 time=13ms TTL=254

Reply from 10.0.0.3: bytes=100 time=12ms TTL=254

Reply from 10.0.0.3: bytes=100 time=11ms TTL=254

Reply from 10.0.0.3: bytes=100 time=10ms TTL=254

Reply from 10.0.0.3: bytes=100 time=9ms TTL=254

Reply from 10.0.0.3: bytes=100 time=8ms TTL=254

Reply from 10.0.0.3: bytes=100 time=7ms TTL=254

Reply from 10.0.0.3: bytes=100 time=6ms TTL=254

Reply from 10.0.0.3: bytes=100 time=4ms TTL=254

Reply from 10.0.0.3: bytes=100 time=3ms TTL=254

Reply from 10.0.0.3: bytes=100 time=2ms TTL=254

Reply from 10.0.0.3: bytes=100 time=501ms TTL=254

Reply from 10.0.0.3: bytes=100 time=499ms TTL=254

Reply from 10.0.0.3: bytes=100 time=497ms TTL=254

[pkhatri]

Hi again,

There is a good reason why you are seeing this (and I mentioned this in my last post)... Since you are using a very small link, every time a large FTP packet is scheduled out the shaping queue, the next (smaller) ICMP packetthat comes along will have to wait for it to be sent out before it can be clocked out. The problem here is the serialisation delay of the large FTP packet.. 1500*8/32000 = 375ms.

The scheduling is working fine. What you need to do when using a small link is to use fragmentation of the competing data packets.

Why don't you try this test ?

Use a shaping rate greater than 1Mbps, which will reduce the serialisation delay of the FTP packets to around 10ms....Then repeat your tests...

Hope that helps - pls rate posts that help.

Regards,

Paresh

[ovt]

Yes, I'm 100% agree, LFI is good thing on low-speed links, but it is supported with FR and PPP only. What should we do with Ethernet? Use PPPoE? Will LFI work?

Also, I'm not sure that using a shaping rate greater than 1 Mbps will help. FTP (or worse - UDP-based traffic) will try to consume all the available bandwidth. This means that several data packets may be queued by the shaper - up to the 1000 ("shape max-buffers"). The voice packet will be delayed anyway.

I'm thinking about DSCP now - shaping queue uses WFQ by default - does this mean that DSCP=ef packets should go out shaping queue first???

Thank you for your help!

[pkhatri · Accepted solution]

Hey Mate,

I do understand where you are coming from here...Understanding how all of this works takes a while to understand and once you do, it's not all that easy to describe it to someone !

Ok, back to the topic at hand...

Agreed that LFI techniques work with FR, PPP, ATM only... There are no real LFI techniques out there especially for Ethernet but then, why would there be? The slowest physical port speed for Ethernet is 10Mbps, after all. Having designed numerous such customer solutions, I can tell you that there aren't too many customers out there who ask for Ethernet services with 256k committed rates !

As to the second part of my post, I'm sure you won't believe me until you try this for yourself... The voice packets will always be scheduled ahead of the FTP (or any UDP packets) as long as you configure them with the priority command. The max latency will be that contributed by any in-flight data packet when a voice packet arrrives (and this will be limited to around 10ms). So pls try it out... you will be surprised.

When using hierarchical policies, the shaping queue is using CBWFQ and not pure WFQ. DSCP will only matter if you configure the classes to match on it...

Once again, pls do rate posts...

Regards,

Paresh.

[ovt]

Now I believe :)

Reply from 10.0.0.3: bytes=200 time=27ms TTL=254

Reply from 10.0.0.3: bytes=200 time=14ms TTL=254

Reply from 10.0.0.3: bytes=200 time=21ms TTL=254

Reply from 10.0.0.3: bytes=200 time=17ms TTL=254

Reply from 10.0.0.3: bytes=200 time=19ms TTL=254

Reply from 10.0.0.3: bytes=200 time=10ms TTL=254

Reply from 10.0.0.3: bytes=200 time=13ms TTL=254

Reply from 10.0.0.3: bytes=200 time=8ms TTL=254

Reply from 10.0.0.3: bytes=200 time=11ms TTL=254

Reply from 10.0.0.3: bytes=200 time=6ms TTL=254

Reply from 10.0.0.3: bytes=200 time=9ms TTL=254

Reply from 10.0.0.3: bytes=200 time=12ms TTL=254

Reply from 10.0.0.3: bytes=200 time=3ms TTL=254

Reply from 10.0.0.3: bytes=200 time=14ms TTL=254

Reply from 10.0.0.3: bytes=200 time=29ms TTL=254

The above is for 1 Mbps shaping.

Thanks again!

[pkhatri]

There you go !

Welcome to the wonderful world of hierarchical QoS.

Regards,

Paresh