Most enterprises have many applications that can be considered mission-critical (trans-actional). However, if too many applications are classified as mission-critical, they will contend among themselves for bandwidth, with the result of dampening QoS effectiveness.
Taken to the extreme, a regular FIFO link (no QoS) is scheduled in the exact same manner as a link where every application is provisioned as mission-critical. Therefore, it is recommended that you classify no more than three applications as mission-critical (transactional).
These applications should be marked with different AF drop-preference values to distinguish them from each other. Such distinctions provide more granular visibility in managing and monitoring application traffic and aid in provisioning for future require-ments. Similar arguments are made for having no more than three applications in a guaranteed bandwidth (bulk data) class of applications and, likewise, marking these applications with different AF drop-preference values.
Default traffic is automatically marked as best-effort (DSCP 0). However, noncritical bandwidth-intensive traffic could (optionally) be marked as different so that adverse policies could be applied to control such traffic. These types of traffic can be described as
“less-than-best-effort” or “scavenger” traffic.
It is imperative that DSCP classification be performed on all packets before they arrive at the WAN edges. In this manner, queuing and congestion avoidance can be performed at the WAN edge based strictly on DSCP markings.
NOTE It’s important to keep in mind that the default class map match setting is match-all.
Therefore, when you attempt to classify mutually exclusive traffic flows (such as differing DSCP values), it is important to explicitly use the match-any qualifier when defining the class map. Another example could be through the use of multiple DSCPs on a single command line:
match ip dscp af11 af12 af13
The advantage of using multiple lines is that this triggers a separate counter in the class-based QoS Management Information Base (MIB) for each DSCP. (If they are matched all on the same line, only a single counter is triggered for all DSCPs.)
The Eight-Class Model introduces a dual-LLQ design: one for voice and another for interactive video. As pointed out earlier in this chapter, the LLQ has an implicit policer that allows for time-division multiplexing of the single priority queue. This implicit policer abstracts the fact that there is essentially a single LLQ within the algorithm and thus allows for the “provisioning” of multiple LLQs.
Interactive video (or IP videoconferencing, also called IP/VC) is recommended to be marked AF41 (which can be marked down to AF42 in the case of dual-rate policing at the campus access edge). It is recommended that you overprovision the LLQ by 20 percent of the IP/VC rate. This takes into account IP/UDP/RTP headers as well as Layer 2 overhead.
Additionally, Cisco IOS Software automatically includes a 200-ms burst parameter (defined in bytes) as part of the priority command. On dual-T1 links, this has proven sufficient for protecting a single 384-kbps IP/VC stream. On higher-speed links (such as triple T1s), the default burst parameter has shown to be insufficient for protecting multiple IP/VC streams.
However, multiple-stream IP/VC quality tested well with the burst set to 30,000 bytes (for example, priority 920 30000). Our testing did not arrive at a clean formula for predicting the required size of the burst parameters as IP/VC streams continually were added.
However, given the variable packet sizes and rates of these interactive-video streams, this is not surprising. The main point is that the default LLQ burst parameter might require tuning as multiple IP/VC streams are added (which likely will be a trial-and-error process).
Optionally, DSCP-based WRED can be enabled on the Interactive-Video class, but testing has shown negligible performance difference in doing so (because, as has been noted, WRED is more effective on TCP-based flows than UDP-based flows, such as interactive video). In these designs, WRED is not enabled on classes such as Call-Signaling, IP Routing, and Network-Management because WRED would take effect only if such classes were filling their queues nearly to their limits. Such conditions would indicate a provision-ing problem that would be better addressed by increasprovision-ing the class’s minimum bandwidth allocation than by enabling WRED.
Additionally, the Eight-Class Model subdivides the preferential data class to separate control plane traffic (IP routing and network-management applications) from business-critical data traffic. IGP packets (such as RIP, EIGRP, OSPF, and IS-IS) are protected through the PAK_priority mechanism within the router. However, EGP protocols, such as BGP, do not get PAK_priority treatment and might need explicit bandwidth guarantees to ensure that peering sessions do not reset during periods of congestion. Additionally, administrators might want to protect network-management access to devices during periods of congestion.
The other class added to this model is for bulk traffic (the Bulk Data class), which is spun off of the Critical Data class. Because TCP continually increases its window sizes, which is especially noticeable in long sessions (such as large file transfers), constraining bulk data to its own class alleviates other data classes from being dominated by such large file transfers. Bulk data is identified by DSCP AF11 (or AF12 in the case of dual-rate policing at the campus access edges). DSCP-based WRED can be enabled on the Bulk Data class
(and also on the Critical Data class). Example 5-4 shows the implementation of the Eight-Class Model for the WAN edge.
This design is more efficient than strict policing, because these bandwidth-intensive noncritical applications can use additional bandwidth if it is available while ensuring protection for critical transactional data classes and real-time voice and video applications.
The development of this model is attributed to Tim Szigeti from the Cisco Enterprise Solutions Engineering Group.
Example 5-4 Eight-Class Model
!
class-map match-all Voice
match ip dscp ef ! IP Phones mark Voice to EF class-map match-all Interactive Video
match ip dscp af41 af42 ! Recommended markings for IP/VC class-map match-any Call Signaling
match ip dscp cs3 ! Future Call-Signaling marking match ip dscp af31 ! Current Call-Signaling marking class-map match-any Network Control
match ip dscp cs6 ! Routers mark Routing traffic to CS6 match ip dscp cs2 ! Recommended marking for Network Management class-map match-all Critical Data
match ip dscp af21 af22 ! Recommended markings for Transactional-Data class-map match-all Bulk Data
match ip dscp af11 af12 ! Recommended markings for Bulk-Data class-map match-all Scavenger
match ip dscp cs1 ! Scavenger marking
!
policy-map WAN-EDGE class Voice
priority percent 18 ! Voice gets 552 kbps of LLQ class Interactive Video
priority percent 15 ! 384 kbps IP/VC needs 460 kbps of LLQ class Call Signaling
bandwidth percent 5 ! BW guarantee for Call-Signaling class Network Control
bandwidth percent 5 ! Routing and Network Management get min 5% Bandwidth class Critical Data
bandwidth percent 27 ! Critical Data gets min 27% BW
random-detect dscp-based ! Enables DSCP-WRED for Critical-Data class class Bulk Data
bandwidth percent 4 ! Bulk Data gets min 4% BW guarantee
random-detect dscp-based ! Enables DSCP-WRED for Bulk-Data class class Scavenger
bandwidth percent 1 ! Scavenger class is throttled to 1% of bandwidth class class-default
bandwidth percent 25 ! Fair-queuing is sacrificed for Bandwidth guarantee random-detect ! Enables WRED on class-default
!
For more information on this approach, go to http://www.cisco.com/application/pdf/en/us/
guest/netsol/ns432/c649/ccmigration_09186a008049b062.pdf.
Case Study: QoS in the Acme, Inc. Network
Acme, Inc. currently uses five different classes of service on the Acme network. For simplicity’s sake, and because of the 3-bit resolution of some QoS technologies, such as 802.1p LAN CoS, MPLS EXP, and IP precedence, Acme IT limits its QoS to classes that can be identified in 3 bits. Traffic is classified at the WAN edge by matching IP precedence values—only the first 3 bits of the ToS byte, which cover 7 DSCP values each.
The policy template shown in Table 5-5 deals with policy marking of packets in Acme. It shows QoS policy for voice, video, and data classifications and their breakout assignments based on circuit speed, allocation per class as a percentage, and the classifications assigned.
Table 5-5 Sample Policy Template Breakdown
IP precedence values 6 and 7 are also used for network control traffic (routing protocols).
Most of this traffic is link-local (CE-PE only), allowing an individual class of traffic to be set up for this traffic on a WAN port with minimum bandwidth. On the CE side of the CE-to-PE links, it is recommended that a separate class be used for management traffic. On the
Policy Number 30 25 20 15 10 5
Bandwidth at Interface Line Rate (in kbps)
Class 622000 155000
45000 to 34000
34000 to 2048
2048 to 1024
1024 to 256
Management 2% 2% 2% 2% 2% 6%
Voice EF
10% 33% 33% 33% 33% 33%
Video AF4
5% 5% 8% 7% 10% 5%
Signaling AF3
5% 5% 5% 5% 5% 10%
Default BE
58% 45% 50% 43% 40% 36%
Scavenger CS1
20% 10% 10% 10% 10% 10%
Total 100% 100% 100% 100% 100% 100%
PE side of the CE-to-PE link, this tends to vary with each provider. This traffic must, at a minimum, be mapped to a high-priority data class of service in the service provider cloud.