QoS: What and Why QoS is used to alleviate occasional network oversubscription. When oversubscription becomes noticeable—that is, when the network traffic increases enough that performance declines—you may choose to give some classes of network traffic better treatment than others. The decisions you make will mean that some users or some applications will be treated better, or at least differently, than others. QoS operation rests on your responses to two broad categories of decisions: -
How to classify traffic— What kind of traffic is this? What are the different classes of traffic on the network? -
How to handle each class of traffic— How should this class of traffic be treated? How is the handling of this class different from that of other classes of traffic? An easy way to understand traffic classes is to think of Olympic medals. Some traffic gets gold-medal treatment, other traffic gets silver-medal treatment, yet other traffic gets bronze-medal treatment, while everything else gets "best-effort" treatment. You have probably seen this kind of distinction with hotels, credit cards, and rental cars. You have to make two sets of decisions, though: Who gets gold-medal handling, and what does gold-medal handling mean? And whatever you decide gold-medal handling is, it should be better than silver-medal handling—and demonstrably so. Otherwise, silver-medal service would be good enough for anyone, and there would be no demand for the gold-medal level of service. Classifying is usually done at the edge of a network; handling is usually done in the middle. Decisions about classifying and handling network traffic are the important business decisions involved in deploying QoS. Networks with no QoS treat all traffic as best effort—the network devices do their best to deliver frames from senders to their receivers. But all traffic is not created equal. When congestion occurs in a network, should some traffic be given premium treatment? For example, should the VoIP traffic be treated better than payroll data transactions? To introduce a metaphor, QoS changes the playing field; it's no longer level. The flavors of preferred handling that premium traffic can receive are almost as varied as network technologies, such as guaranteed bandwidth, a guaranteed path, low delay, high throughput, low data loss, higher priority during congestion, or some combination of these. This section began with the statement that QoS is useful in an oversubscribed network. But because QoS inherently treats some traffic poorly, it is not something you want working hard day and night. Ideally, the network will run smoothly without QoS, except in cases of congestion, where QoS helps some traffic to the detriment of other traffic. This brings us to the two guidelines for QoS usage: How do you know that you have a congestion problem? Congestion can be observed when one or more of your performance measurements (delay, jitter, or packet loss) intermittently go bad. That is, most of the time, voice quality is good, because these measurements are in an acceptable range. But every once in a while, during heavy network usage, one or more of these measurements spike upward. The goal of QoS is to smooth out the spikes. What does congestion on your network look like on a daily, weekly, and monthly basis? Your network administrator probably has graphs showing the frequency, duration, and location of network congestion. For chronic congestion, QoS is not the solution. QoS treats some traffic poorly, and it merely postpones the inevitable failure that occurs when new users and more traffic are added. Nor are QoS techniques designed to solve static problems that exist when there is no congestion present. For example, if delay or packet loss is consistently high, even when the network is being lightly used, you need to resolve the underlying problems instead of looking for QoS solutions. In Chapter 3, "Planning for VoIP," the section "Working on the Problem Areas" describes the right approaches to chronic congestion and static problems in some detail: adding more bandwidth, upgrading or replacing existing network equipment, laying out your network architecture in a more efficient configuration, reconfiguring or retuning the network, or a combination of these. Even if your network is a good candidate for QoS, it is still worth exploring the alternatives, particularly cheap bandwidth and a network design with fewer bottlenecks. But, more bandwidth does not always help, especially where delay and jitter are involved, although it does give all of your network traffic more headroom. Finally, QoS has a few downsides, which are explored in this chapter: -
It is difficult to set up. -
It often involves political decisions, determining who is in each class of traffic and how they get treated. In some situations, QoS is not used for fear of making the wrong political decision—for example, giving priority to the billing department by sacrificing the CEO's traffic. Using QoS for VoIP—a business-critical application—may be politically easy, however. -
QoS roll out and deployment tools must become part of your standard equipment. Traffic generators are discussed later in this chapter, and policy-based network management is discussed in Chapter 6, "Ongoing VoIP Management." -
QoS presents considerable testing challenges. For one thing, QoS works only when congestion occurs. Testing should show how the different traffic classes get handled differently, particularly under high-stress conditions, and needs to demonstrate what happens on the network from end to end. -
Network management tools for QoS are not extremely mature. You would like to see at a glance the answer to questions like these: Is it working? Is it helping? Is it deployed right? What changed? Where? Having admitted the challenges, it is time to tackle them, and really take advantage of the power that QoS offers. Classifying Traffic To be classified, network traffic needs to be segregated. For example, some network applications are easily identified because they use a unique IP port number. By contrast, applications that use dynamic ports are hard to identify solely by looking at port numbers. Of the many ways in which network traffic can be classified, here are some of the most common: -
Protocol (such as TCP, UDP, RTP, ICMP) -
IP header settings, such as the DiffServ/TOS byte -
Resource Reservation Protocol (RSVP) signaling -
Port numbers and IP addresses -
RTP header information -
Data content (such as a URL) -
Data rate and flow patterns -
Buffer size -
Routing tags -
Application signature For some of these methods, classification is accomplished using some implicit characteristic already present in the IP packet, such as its protocol, destination address, or port number. Otherwise, the classification is done explicitly. Differentiated services (DiffServ), RSVP, and routing tags are discussed later in this chapter; at any rate, some application or device has to take explicit action to identify traffic to be handled with one of these techniques. Traffic classification can be done in any of three ways: -
At the edges of a network— Devices that classify traffic at the network edge are common today. Edge devices, such as traffic shapers, bandwidth managers, access routers, and firewalls, provide central points of administration. You can secure the edge devices and apply a consistent set of traffic rules at the places through which most traffic passes. Classification works best when the traffic goes through devices like these. But beware: These same places can become bottlenecks, compounding performance problems. -
In the middle of the network— Traffic classification in the middle of the network is also common, but the devices usually have less knowledge about the traffic. Routers, for example, may classify traffic based on flow rates per connection, queuing conditions, and packet sizes, rather than on content or address. -
By the network applications themselves— End users and applications themselves are rarely trusted to classify traffic. If they are given a choice, most users want their traffic to receive premium handling. As a result, sophisticated billing methods—that is, ways to charge a premium for traffic given premium handling—are needed for all network users. Thus, applications generally classify their own traffic only when the applications know how to employ the right settings, their users are trusted, and all network devices in the path honor the application settings. VoIP applications often do their own classification; for example, softphones, IP phones, and VoIP gateways are generally good at explicitly marking their call setup and VoIP conversation traffic. Handling Traffic Having identified and classified the traffic, you also need to determine what you are going to do with it, but understand that your decisions will produce side effects when things get bad, such as discarding packets or adding delay to the nonpremium traffic. For each class of traffic, a series of QoS configuration decisions determines how it is handled at each hop as it traverses a network. Should it be given high, medium, or low priority? Should it get a guaranteed amount of bandwidth or guaranteed latency? During congestion, should it be treated as less likely to be discarded? Does it require a guaranteed route across the network? For VoIP conversation traffic, focus on its delay sensitivity. You don't want the VoIP datagrams to get stuck in a router queue. You don't want them in competition with transaction-oriented traffic. QoS configuration changes that enable the appropriate handling for each class of traffic are made to network devices that are at the edges and in the middle of a network. However, the results of the configuration changes are seen by the end users of the applications. This wide separation of cause (configuration changes) and effect (end-to-end behavior) is one of the challenges of setting up QoS successfully. |
