| Configuring QoS to do what you need for your network can be a daunting task. You are confronted with many different mechanisms to learn about and, unfortunately, not all vendors implement them exactly the same way. In addition, instead of talking in terms of bit fields and traffic classes, you would probably like to define your QoS configuration in terms that are easier to understand. Why is it so difficult to set up QoS so that it functions well in a network? The following are some of the reasons: -
Many QoS schemes and parameters in use today— This chapter has introduced more than a dozen QoS and tuning techniques. Each has its own terminology, its own parameters, and its own peculiarities, which are new to most network personnel. -
Lack of knowledge and experience on the part of network IT staff— Much of QoS is new technology to your team, and there are not many good tips and techniques broadly available. Also, QoS changes are discouraged in many networks, so your team may not have had any opportunity to experiment and gain firsthand knowledge. -
Many device interconnections and interactions— Most broad QoS plans involve changes in devices throughout a network, not just in a single router or on a single link. Many network devices and applications may be involved. Mismatches in device setup can occur at any of them. The large "cross-product" of potential problems makes setup particularly error prone. -
QoS handling is imperceptible under light load— QoS effects can generally only be observed against heavy traffic—that is, under stress conditions. So, QoS testing requires a congested network -
- To detect its behavior. -
- To see if it is configured right. -
- To show some classes getting improved handling. -
- To see if it still works right after making any change. -
- To see if you are getting the premium handling you paid for. Configuring network devices one at a time, by hand, is so error prone that it may be out of the question for many large networks. Fortunately, a new set of tools—policy-based network management software—offers the usability needed to make QoS tenable. Policies make it much easier to understand the QoS choices you are making and which devices are affected. These policies are discussed in Chapter 6. But even with better tools, your team still needs solid experience in how QoS behaves both when it is performing correctly and when it is set up incorrectly. Your team needs to test its work, in small settings and in large ones, before applying its changes network-wide. A QoS Testing Plan The goal of testing is to make sure something functions as expected, and when it fails, that it fails as expected. Because QoS configuration is very complex and involves the interaction of many different network components, testing is required. You don't want to wait until after you have spent weeks implementing a new QoS scheme to find out that it does not work. QoS and tuning changes pose grand testing challenges. You need reliable, repeatable tests that can be run over and over again each time a parameter is changed slightly. Testing QoS mechanisms poses unique difficulties. First of all, if QoS schemes go to work only when the network becomes congested, how do you know a scheme is really working unless the network is experiencing congestion? Some network test tools, such as NetIQ's Chariot[10], can send broad patterns of application traffic over a network. They can generate enough background traffic to create congestion, to which you can then add the "traffic under test," the traffic streams that the QoS mechanisms are intended to work on. You can do all of this in a reliable, repeatable manner, so that when QoS goes into production, it functions exactly as expected. For the testing that occurs in a lab rather than on the production network, be certain that the lab traffic accurately represents the production traffic. Otherwise, the values you select will only make sense in the lab and may have either no or undesirable effects in the production network. Your test plan should take into account two basic approaches to QoS testing: -
Before and after— Start with the QoS handling technique deactivated. Run a baseline test, consisting of background traffic and traffic in the class that is to get special handling. Then, activate the QoS handling technique, run the same traffic again, and compare the results against the baseline results. Make sure the background traffic variables have not changed, and that the affected traffic class actually shows the effects of improved handling. -
Mix of classes— Start with the QoS handling technique activated. Inject identical traffic with different classifications into the network. The traffic in different classes should be handled differently. Measure the results in terms of the network statistics you are interested in: throughput, response time, delay, lost data, and jitter. Every time you change any QoS parameter, run another test. Run tests before enabling QoS changes and after making any QoS changes. The section "Performance Requirements," earlier in this chapter, introduced the network measurements that are most relevant to VoIP performance. For VoIP traffic, the QoS and tuning techniques you apply should result in a higher MOS, by offering lower delay, lower jitter, and fewer lost packets. Keep testing and tuning QoS until you are sure that you have reached your MOS target, even under congested conditions. |
