Hierarchal QoS policies

HQoS

A final element to consider about MQC-based QoS tools is that these can be combined in a hierarchical fashion, meaning, MQC policies can contain other “nested” QoS policies within them. Such policy combinations are commonly referred to as Hierarchal QoS policies or HQoS policies. HQoS policies are crucial in some TelePresence deployment scenarios, particularly with respect to subline rate services like Metro Ethernet or MPLS VPN services (with Ethernet handoffs).

Syntactically, HQoS policies can be constructed within MQC by attaching the service-policy command to a per-class action within a policy map, rather than to an interface. Incidentally, the output keyword is not required for such a policy because this is implied.

Consider a couple of examples where HQoS policies might be useful. First, look at an example of nested HQoS policies using the same QoS tool (such as a hierarchical policer), and then take a look at HQoS policies using a combination of different QoS tools (such as an HQoS shaping with queuing policy).

In the first case, you might encounter scenarios where some applications require policing at multiple levels. For example, it might be desirable to limit all TCP traffic to 5 Mbps, while, at the same time, limiting FTP traffic (which is a subset of TCP traffic) to no more than 1.5 Mbps. To achieve this nested policing requirement, Hierarchical Policing can be used.

The policer at the second level in the hierarchy acts on packets transmitted or marked by the policer at the first level. Therefore, any packets dropped by the first level are not seen by the second level. Up to three nested levels are supported by the Cisco IOS Hierarchical Policing feature.

Example 1 shows the configuration for the nested, two-level, hierarchical policing of TCP and FTP traffic.

Example 1: Hierarchical Policing Policy Example

---

Router(config)# policy-map FTP-POLICER
Router(config-pmap)# class FTP
Router(config-pmap-c)# police cir 1500000
Router(config-pmap-c-police)# conform-action transmit
Router(config-pmap-c-police)# exceed-action drop
Router(config-pmap-c-police)# violate-action drop
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# policy-map TCP-POLICER
Router(config-pmap)# class TCP
Router(config-pmap-c)# police cir 5000000
Router(config-pmap-c-police)# conform-action transmit
Router(config-pmap-c-police)# exceed-action drop
Router(config-pmap-c-police)# violate-action drop
Router(config-pmap-c-police)# service-policy FTP-POLICER

---

Figure1 illustrates the logic of this hierarchical policing example.

 
Figure 1: Hierarchical policing logic example

Additionally, it is often useful to combine shaping and queuing policies in a hierarchical manner, particularly over subline rate access scenarios.

As previously discussed, queuing policies only engage when the physical interface is congested (as is indicated to IOS Software by a full Tx-Ring). This means that queuing policies never engage on media that has a contracted subline rate of access, whether this media is Frame Relay, ATM, or Ethernet. In such a scenario, queuing can be achieved only at a subline rate by introducing a two-part HQoS policy wherein

• Traffic is shaped to the subline rate.
• Traffic is queued according to the LLQ/CBWFQ policies within the subline rate.

With such an HQoS policy, it is not the Tx-Ring that signals IOS Software to engage LLQ/CBWFQ policies, but rather it is the Class-Based Shaper that triggers software queuing when the shaped rate has been reached.

Consider a practical example: A service provider offers an enterprise subscriber a GigabitEthernet handoff, but with a (subline rate) contract for only 60 Mbps, over which he wants to deploy IP Telephony and TelePresence and data applications. Normally, queuing policies will engage only on this GE interface when the offered traffic rate exceeds 1000 Mbps. However, the enterprise administrator wants to ensure that traffic within the 60 Mbps contracted rate is properly prioritized prior to the handoff so that both VoIP and TelePresence are given the highest levels of service. Therefore, he configures an HQoS policy so that the software shapes all traffic to the contracted 60 Mbps rate and attaches a nested LLQ/CBWFQ queuing policy within the shaping policy so that traffic is properly prioritized within this 60 Mbps subline rate. Finally, the shaping policy (with the nested queuing policy) is attached to the GE interface, as shown in Example 2.

Example 2: Hierarchical Shaping and Queuing Policy Example

---

Router(config)# class-map match-all VOIP
Router(config-cmap)# match dscp ef
Router(config-cmap)# ! Matches VoIP on DSCP EF
Router(config-cmap)# exit
Router(config)# class-map match-all TELEPRESENCE
Router(config-cmap)# match dscp cs4
Router(config-cmap)# ! Matches TelePresence on DSCP CS4 (per RFC4594)
Router(config-cmap)# exit
Router(config)#
Router(config)# policy-map LLQ-CBWFQ
Router(config-pmap)# class VOIP
Router(config-pmap-c)# priority percent 10
Router(config-pmap-c)# ! Provisions 6 Mbps of LLQ for VoIP
Router(config-pmap-c)# class TELEPRESENCE
Router(config-pmap-c)# priority percent 25
Router(config-pmap-c)# ! Provisions 15 Mbps of LLQ for TelePresence
Router(config-pmap-c)# class CALL-SIGNALING
Router(config-pmap-c)# bandwidth percent 5
Router(config-pmap-c)# class TRANSACTIONAL-DATA
Router(config-pmap-c)# bandwidth percent 20
Router(config-pmap-c)# class BULK-DATA
Router(config-pmap-c)# bandwidth percent 10
Router(config-pmap-c)# class class-default
Router(config-pmap-c)# fair-queue
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# 
Router(config)# policy-map HQoS-60MBPS
Router(config-pmap)# ! HQoS Shaping policy
Router(config-pmap)# class class-default
Router(config-pmap-c)# shape average 60000000 1200000
Router(config-pmap-c)# ! Rate=650Mbps; Bc=1.2Mb, Tc=20ms
Router(config-pmap-c)# service-policy LLQ-CBWFQ
Router(config-pmap-c)# ! Forces queuing policy to engage at sub-line rate
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)#
Router(config)# interface GigabitEthernet0/1
Router(config-if)# description Access Edge (60 Mbps CIR over GE)
Router(config-if)# service-policy output HQoS-60MBPS
Router(config-if)# ! Attaches HQoS policy to GE interface
Router(config-if)# exit

---

Figure 2 illustrates the underlying mechanisms for this HQoS policy.

 
Figure 2: HQoS Policy: Shaping to a Subline Rate with Queuing Within the Shaped Rate

Dropping Tools | Network Quality of Service

Although generally dropping policies is not applicable for TelePresence flows, these do play an important part in the overall QoS policy design on TelePresence networks. Dropping tools are complementary to (and dependent on) queuing tools; specifically, queuing algorithms manage the front of a queue (that is, how a packet exits a queue), whereas congestion avoidance mechanisms manage the tail of a queue (that is, how a packet enters a queue).

Dropping tools, sometimes called congestion avoidance mechanisms, are designed to optimize TCP-based traffic. TCP has built-in flow control mechanisms that operate by increasing the transmission rates of traffic flows until packet loss occurs. At this point, TCP abruptly squelches the transmission rate and gradually begins to ramp the transmission rates higher again. Incidentally, this behavior makes a strong case against the statement that “QoS isn’t necessary; just throw more bandwidth at it.” Because if left unchecked, lengthy TCP sessions (as are typical with bulk data and scavenger applications) will consume any and all available bandwidth, simply due to the nature of TCP windowing.

When no congestion avoidance algorithms are enabled on an interface, the interface is said to tail drop. That is, after the queuing buffers have filled, all other packets are dropped as they arrive.

In a constricted channel, such as in a WAN or VPN, all the TCP connections eventually synchronize with each other as they compete for the channel. Without congestion avoidance mechanisms, they all ramp up together, lose packets together, and then back off together. This behavior is referred to as global synchronization. In effect, waves of TCP traffic flow through the network nodes, with packets overflowing the buffers at each wave peak and lulls in traffic between the waves.

Figure 1 illustrates TCP global synchronization behavior attributable to tail-dropping and the suboptimal effect this behavior has on bandwidth utilization.

 
Figure 1: TCP global synchronization

Random Early Detect (RED) counters the effects of TCP global synchronization by randomly dropping packets before the queues fill to capacity.

Instead of waiting for queuing buffers to fill before dropping packets, RED causes the router to monitor the buffer depth and perform early discards (drops) on random packets when the defined queue threshold has been exceed.

RED drops occur within the operational bounds of TCP retry timers, which slow the transmission rates of the sessions but prevent these from slow-starting. Thus RED optimizes network throughput of TCP sessions.

Because UDP does not have any retry logic, congestion avoidance techniques such as RED (and variants) do not optimize UDP-based traffic.

Note

Cisco IOS Software does not (directly) support Random Early Detect (RED), only Weighted-RED (WRED), discussed in the next section. However, if all packets assigned to a WRED-enabled queue have the same IP Precedence or DSCP markings, the effective policy is simply RED.

Shaping Tools | Network Quality of Service

Shapers operate in a manner similar to policers in that they invoke token bucket algorithms to meter traffic. However, the principle difference between a policer and a shaper is that where a policer re-marks or drops traffic as a policy action, a shaper merely delays traffic. Even though TelePresence is a real-time application, you might encounter scenarios, such as subline rate access scenarios, which require shaping policies to be included within a comprehensive TelePresence QoS policy. Figure 1 illustrates generic traffic shaping.

 
Figure 1: Generic traffic shaping effect on traffic flow

Shapers are particularly useful when traffic must conform to a specific rate of traffic to meet a service-level agreement (SLA) or to guarantee that traffic offered to a service provider is within a contracted rate. Additionally, shapers have long been associated with Non-Broadcast Multiple-Access (NBMA) WAN topologies, such as ATM and Frame Relay, where potential speed-mismatches exist. However, shapers are becoming increasingly popular on newer Layer 3 WAN access circuits, such as Ethernet-based handoffs, to conform to subline access rates.

Shapers, like policers, use token bucket algorithms. On most platforms, by default, IOS shapers set the Bc to equal CIR/8, which yields an interval (Tc) of 125 ms. Although this interval value might be adequate for data applications, it introduces unnecessary interpacket delays for real-time networks. Consider the example shown in Figure 2.

 
Figure 2: Shaping behavior with default Bc values

A shaper uses the CIR, Bc, and Be to smooth a traffic stream to a specified rate. It achieves the given CIR by taking the line speed of the interface and dividing it into equal length timeslots (Intervals, or Tc) and then sends a smaller portion (Bc) of the traffic during each timeslot. The timeslot size is governed by the Bc parameter (Tc = Bc / CIR). In Figure 2, a line rate of 128 kbps is shaped to 64 kbps. The Bc, by default, is one eighth of the CIR (or eight kbps). Each second is divided into eight timeslots of 125 ms each, and the shaped rate of 64,000 bps is divided into eight bursts of 8000 bps each (Bc). Each burst will take 62.5 ms to transmit (at a 128 kbps line rate). So the shaper transmits information for the first 62.5ms of each 125 ms timeslot and is silent for the remaining 62.5 ms of the timeslot. Over the span of a second, this achieves the average rate of CIR.

Additionally, you can use the Be value to determine the peak Rate of sending, which is calculated as follows:

Peak Rate = CIR (1 + Be / Bc)

Peak-rate shaping allows the router to burst higher than average-rate shaping. However, when peak-rate shaping is enabled, any traffic exceeding the CIR can be dropped if the network becomes congested.

A router interface might be configured to shape using average rates, through the shape average policy-action command, or to a peak rate, through the shape peak policy-action command. The configuration for a basic Class-Based Shaping policy to shape to an average rate of 5 Mbps is as follows:

Router(config)# policy-map CB-SHAPING-5MBPS
Router(config-pmap)# class class-default
Router(config-pmap-c)# shape average 5000000

Because shaping involves buffering, various queuing techniques might be activated when the shaping buffer has been filled to capacity.

Policing Tools | Network Quality of Service Technologies

Policers monitor traffic flows and identify and respond to traffic violations. For example, policers can monitor TelePresence flows at the campus access edge. Because TelePresence flows are bounded (to typically 5 Mbps per screen at 1080p), flows in excess of such bounds would be indicative of network abuse and can be immediately identified and responded to by policers.

Policers achieve these objectives by performing ongoing checks for traffic violations and taking immediate prescribed actions when such violations occur. For example, a policer can determine if the offered load is in excess of the defined traffic rate and then drop the out-of-contract traffic, as illustrated in Figure 1.

 
Figure 1: A generic policer

Additionally, policers can re-mark excess traffic to identify (but not necessarily drop) traffic that exceeds a given traffic contract, which might be valuable for reporting, billing, or capacity planning purposes. In such a role, the policer is called a marker. Figure 2 illustrates a policer functioning as a marker.

 
Figure 2: A policer as a marker

Cisco IOS policers are modeled after token bucket algorithms. Essentially, these algorithms are metering engines that keep track of how much traffic might be sent to conform to the specified traffic rates.

A token, in everyday use, is an item given to an individual that represents the right to use a given service, such as to ride on the subway or to play a video game, and so on. In QoS terminology, a token permits the policing algorithm to send a single bit (or in some cases, a byte) of traffic. Typically, these tokens are granted at the beginning of a second, according to the defined policing rate, referred to as the Committed Information Rate (CIR).

Tokens granted at the beginning of each second of operation are placed in a logical cache, referred to as the bucket. A key difference in policing algorithms is how unused tokens are dealt with at the end of each second: Some policers allow unused tokens to accumulate in the bucket, whereas others force unused tokens to be discarded. These differences, and the effects on traffic policing, is discussed in more detail shortly.

For example, if the CIR is set to 8000 bps, then 8000 tokens are placed in the bucket at the beginning of each second. Each time a bit of traffic is offered to the policer, the bucket is checked for tokens. If there are tokens in the bucket, the traffic is passed. One token is removed from the bucket for each bit of traffic that is passed, and such traffic is viewed to conform the rate, and the specified action for conforming traffic is taken. (The conforming traffic is typically transmitted unaltered.) When the bucket runs out of tokens, any additional offered traffic is viewed to exceed the rate, and the exceed action is taken. (The exceeding traffic is either re-marked or dropped.)

In addition to defining the CIR, policers require that a committed burst (Bc) also be defined. The committed burst, also known as the normal burst, refers to the bytes allowed in a subsecond traffic burst before packets will be considered to exceed the rate limit.