QoS Design Guidelines

As discussed in Chapter 1, the first step in any design process is to determine the requirements that you are trying to meet. Only then should you attempt to design the network features to meet those requirements. Recall that this process is called a top-down approach. Compare this to a bottom-up approach, in which features (queuing, for example) are deployed on some interfaces without considering why they are being deployed.

Thus, when designing QoS features into your network, the QoS-related requirements of the network must be clearly defined. For example, if the network includes VoIP, video, or other delay-sensitive traffic, you need to determine whether that traffic is considered important enough to warrant providing it strict priority.

The number of classes of traffic that are to be used in the network and which applications are to be considered mission-critical need to be determined. In general, the number of applications in the Mission-Critical class should be minimized. If too many are considered critical, each one becomes just part of a large group and does not necessarily get the services it truly needs.

QoS can be considered "a system of managed unfairness"^[9] in that some traffic is given less priority than other traffic, which might be seen by some users to be unfair. Thus, it is important to get agreements and buy-ins from high-level management about which data is considered critical to and within the organization, and to flow the QoS requirements from these agreements. Any complaints of unfairness can then be rebuked by referring to the agreements.

QoS tools can be used in all areas of the Enterprise Composite Network Model. As discussed earlier, the ideal trust boundarywhere classification and marking of traffic are performed and trusted by the rest of the networkis as close to the end devices as possible. While the network administrator might not want to trust end users or their applications to set markings consistent with the network's policy, the access switches to which the users' PCs are connected could perform this task.

Using Layer 3 DSCP QoS markings allows QoS to be provided end to end throughout the network. If some access switches support only Layer 2 (CoS) markings, these markings must be mapped to the appropriate DSCP values; this would be a function performed by the distribution switches. These switches must also apply DSCP values to any traffic that has not been marked elsewhere. The campus core should not be involved in classifying and marking traffic; its role is to process the traffic quickly, based on previous markings.

Policing (dropping) traffic is best performed as close to the source of the traffic as possible, to avoid having the traffic travel through the network (and therefore consume resources such as bandwidth) unnecessarily. Again, within the campus infrastructure, policing should be performed on the access or distribution devices.

QoS tools can be enabled on either switches or routers. When performed in software however, QoS operations can consume considerable CPU resources, so ideally they should be enabled on devices that execute the necessary computations in hardware to achieve higher performance.

Although we typically think of applying queuing only to slow WAN links, LAN links can also be congested. For example, uplinks between switches that aggregate traffic from many other links are potential locations of congestion. Although this is less likely to occur than on WAN links, queuing should be deployed on any link that could potentially experience congestion, to provide the needed services to the network traffic. Queuing policiesin other words, how each traffic class is handledshould be consistent across the enterprise.