Flat QoS vs Hierarchical QoS(H-QoS)

Flat QoS：

In flat QoS, all classes are created at the same level. When all classes are on the same level, the types of QoS policies that can be represented are limited. For example, suppose you want to create a hub with two classes to represent remote offices for San Francisco and New York, then apply a QoS policy to segregate traffic flow within the San Francisco office. Because you cannot define a subclass within the San Francisco spoke, the traffic flow is difficult to segregate. The following figure illustrates a flat QoS structure.

H-QoS：

H-QoS provides a way to create a hierarchical QoS structure that supports parent and child classes. You can use a parent and child structure to segregate traffic for remote offices based on flow source or destination. This is a way to effectively manage and support remote sites with different bandwidth characteristics.

For example, a QoS hierarchy can represent a hub site that uses parent classes for the two spoke offices of San Francisco and New York. For each parent class, you can define child subclasses. The child subclasses can then use both rate shaping and prioritization to regulate the interaction of traffic at the site.

When to Use Flat versus H-QoS

Generally speaking, you create a flat QoS structure when you have a simple QoS schema or need to use link share weights.

You create a H-QoS structure when you:

• have a complex QoS schema and need to simplify its management. The Management Console provides a view of the QoS class tree and its associated rules table for easy administration.
• have remote sites that require a different mix of guaranteed bandwidth or latency for their applications.
• want to share excess bandwidth between class groupings (remote sites).
• have virtual in-path deployments; in this case H-QoS is required.