Designing QoS policy elements

The purpose of the QoS Policy is to determine which limit, guarantee, or priority is given to traffic marked with a certain QoS Class.

Each QoS Class can appear in only one (active) rule on each tab of a QoS Policy. The same QoS Class can be used on both the QoS tab and the DSCP Match/Mark tab of the same QoS Policy. The order of the QoS rules does not matter. The classification of the traffic is made using Access rules.

Except for the QoS Class, all other cells for rules on the QoS tab are optional. However, at least one of the other cells must be filled for the rule to affect the traffic. None of the cells exclude any of the other cells, so you are free to select which cells you want to use for any given QoS Class. It is not necessary to define the use of all available bandwidth in your QoS Policy. The bandwidth outside the guarantees, as well as bandwidth within the guarantees that is not used for traffic, is used to handle the traffic that has no specific QoS rule. The traffic is handled on the normal first-come-first-served-basis, using the medium priority of 8.

CAUTION:
If your guarantees are equal to the total throughput of an interface, any traffic without a guarantee is blocked if all guarantees are fully used.

When you save the QoS Policy, the system checks for contradictions within each rule, such as a rule that sets a limit that is lower than the guarantee for the same rule. When you refresh the engine’s configuration, the QoS Policies defined for the engine’s interfaces are checked again, comparing the QoS rules to the throughput values set for the interfaces. The values can be automatically scaled down if the sum of all guarantees in the QoS Policy exceeds the interface’s throughput. However, the values are never scaled up.

The values for the bandwidth limits and guarantees can be entered either in kilobits or as percentages of the total throughput of the interface. Technically, nothing prevents you from using both ways of entering values even in the same rule. However, it is recommended to use one way of entering the values consistently throughout each QoS Policy. Using mixed methods of entering the values makes it more difficult for the administrators to read the QoS policy. Mixed methods can also prevent the system from checking for issues when you save the QoS Policy, as the throughputs of the interfaces are not known. If the QoS Policy cannot be checked when you save it, it is checked when the Engine Policy is installed. Mistakes in the QoS Policy can prevent you from installing or refreshing the Engine Policy.