QoS H-QoS – Understanding Hierarchical QoS

h-qosqos

As I understood, the main difference between H-QoS and QoS is the level of category granularity, in which we could apply different QoS tools and policies. For example in simple QoS, just differentiation between services is possible(like different priorities for voice, video, date and so on), but when H-QoS comes in, it will be possible to apply QoS policies to different users, VLANs, maybe logical interfaces and so on.

Is that all about H-QoS? or maybe I'm completely wrong?

Best Answer

The main difference is that with HQoS, policies are applied bottom-up in hierarchical order, rather than being applied independently at different levels.

Let's take a simplified two-level example with subscriber-level and VLAN-level, where there are multiple subscribers per VLAN, with data rate limits for each. Suppose all subscriber traffic exceeds the VLAN limit by 2%, but two of the subscribers exceed their subscriber limits by 10%.

If we apply the VLAN limit to all traffic without considering the per-customer limit, we'd drop 2% of all traffic on the VLAN. Yet if we had applied the per-subscriber limit first and only consider non-dropped traffic for the per-VLAN limit, we might end up being below the per-VLAN limit and not have to drop any other customer traffic at all. So, well-behaved subscribers could be punished for the behavior of the oversubscribers, which is not what we want.

With non-hierarchical QoS, you get no guarantees about the order, and in many implementations there would be no order at all: both levels would be applied independently and concurrently, so not only would you end up with lower throughput than the VLAN limit, but the two oversubscribing customers would get less than their traffic limit.

With HQoS, each oversubscribed customer gets 10% dropped, and every customer (including these two) get an equal percentage dropped as necessary to bring the rest of the traffic under the per-VLAN limit.

With an implementation that applies QoS at different levels concurrently, all customers would have 2% of traffic dropped. In addition, the oversubscribed customers would have 10% of their traffic dropped. Some packets would be marked for dropping by both limiters, so the total drops for these customers would be just under 12% (actually 10% + 2 % - (10% * 2%)).

Related Solutions

Ethernet switch capable of H-QoS at the 802.1q level

While I don't think it's as "robust" as H-QoS/giving percentages based on DSCP values and would probably require more configuration overhead, you could rate-limit outbound against L2 ACL's that reference a VLAN. Example:

policy-map 10Mbps
  cir 9992688 cbs 32768 eir 0 ebs 1250 excess-priority 0

!numbered access lists in the range of 400-599 are for L2 MAC access lists
access-list 400 permit any any 2000 etype any
!2000 will represent the VLAN ID

interface ethernet 1/1
  qos pcp encode-policy off     ! preserve outer VLAN CoS if applicable
  rate-limit strict-acl         ! drop traffic that's denied by a rate-limiting ACL
  rate-limit output access-group 400 policy-map 10Mbps

According to the docs, you can bind multiple rate limiting policies to a single port, however once a matching ACL clause is found for a packet, the device doesn't evaluate subsequent clauses in the rate limiting ACL and subsequent rate limiting ACLs.

As to setting EF, instead of doing that you may be able to commit to 25% of the 10Mbps and the rest can go to an EIR/EBS value.

Cisco – QoS woes – managed IP VPN

To answer your questions:

RDP traffic should get up to the 25% of the remaining bandwidth. Where the already reserved bandwidth is the 35% ( class-default gets 25% by default and EF get 10% ). So, if i'm right, you assigned ~665Kbps to RDP. Anyway you should check if you're dropping packets issuing the command below:

show policy-map <your wan interface> output class REMOTEDESKTOP

and checking for dropped packets.

Cisco assign a queue to each user-defined class that includes the bandwidth or police commands. To make a long-story simple those commands define the amount of bandwidth assigned to every queue during congestions.
In theory every TCP based stream should be OK with drops. In practice some of them aren't. Dropping precedence bits tell the routers what packets should be dropped, within a given class, before congestion happens. Since RDP is the only type of traffic defined in your REMOTEDESKTOP class, you should not worry about it.
Bandwidth percentage are not in order ( as Jeremy stated ).

That said, there are a lot of things that i would change in your configuration:

There are no matches between some of classes of the setTos and the useTos policy-map. For instance the one named AF-HIGH is processing no packets since no class in setTos sets DSCP to AF41.
BE class in setTos is somehow self-defeating since it makes the class-default class useless. Note that class-default is the only system-defined class and get the 25% of the bandwidth by default ( 100 - max-reserved-bandwidth ) .
bandwidth remaining percent is not the best options ( as Jeremy explained ). I would change it to bandwidth percent.
I would prefer to mark EF packets by myself and not to rely on the phones' settings.

Best Answer

Related Solutions

Ethernet switch capable of H-QoS at the 802.1q level

Cisco – QoS woes – managed IP VPN

Related Topic