Stress Is on QoS, The

Enterprise Networks & Servers, Jan 2005 by Welcher, Peter J

There are 10 (binary) kinds of people: those who have been reading these articles and those who haven't. The second group will probably never see these words. Those in the first group may have noticed I like to talk about things I've been doing. I hope this keeps the topics fresh and real-world. It certainly helps me out with having to do less preparation before writing.

This month is another article relating to work I've been doing.

I and some of our other folks have been working on a QoS project for a large network. We're describing the architecture, the configurations, things to consider, initial testing and deployment, etc. in the customer's specific environment. One of the tasks was testing and demonstrating QoS in the lab. (Stress-testing QoS, hence the title). We put together a set of freeware and used it for this. Feedback suggests the demo is effective.

The original idea for this sort of thing is something I first saw with a Cisco SE in San Francisco, Eric Mar, who had a road show QoS Boot Camp a few years back. He was kind enough to run through it for me and some others. It provided the core idea for the DQOS course labs when I and some other folks wrote the initial outline. (No, I didn't write the actual course slides and materials). Since then, I've borrowed ideas from the now-retired DQOS course labs, and some other sources, including some quick and dirty demos I've done over time.

The key idea here is to vividly demonstrate the benefits of QoS. For Cisco, the intent was indubitably sales and showing off the new capabilities that differentiated Cisco routers. For you and me, the goal might be to demonstrate the value and efficacy of QoS to management, consulting customers, etc. If you want your management chain to allocate time, training, staff, or money for QoS, they need to understand what it does for the network and why its important.

Vivid here means either showing something or (as a fallback) listening to something. seeing is believing. Dry numbers in show command output or some test tool window may be more informative, but are less effective, particularly with not-so-technical managers.

This article describes in general terms how you can put together your own QoS demo. I don't want to give away all our secrets and added value, but a lot of what I've been doing is something you can do on your own. This is also a great way to work with QoS in a lab, looking at the technical information and seeing how that correlates with what you're seeing or hearing.

The Basic Idea

The way the demo works is to congest a link that carries loading traffic plus the demo traffic. You then show how ugly things are without QoS, and then apply QoS to the interface to make some things better. It can be particularly effective if you have two video streams or two phone calls, and only one is improved. That makes it evident that the congestion and packet drops are still present, but that QoS has protected the important traffic.

Important thing to note: QoS is not a panacea, and doesn't make up for not having enough bandwidth. QoS provides priority access to the bandwidth winners, which implies there are also losers. Don't let your boss leave the demo thinking QoS will make any amount of video or audio work. Nor will it replace buying more bandwidth, although QoS may allow you to delay having to buy more bandwidth for a little while. The point to make is that QoS can protect important traffic, IF you have enough bandwidth for that traffic plus some left over for the remaining Best Effort Traffic.

You do have to tune what you demo to the bandwidth on the link. I suggest you not do demos on Gigabit Ethernet. You would probably need some costly power tools or several computers to generate enough traffic to congest it. Rather, work with fractional-Tl to, say, 6Mbps links. This reflects most real-world WAN links today, except perhaps at corporate HQ or data center. Congesting links at this speed doesn't take a lot of effort, and yet you can run some fairly interesting multimedia traffic over them for demo purposes. Serial links are good for the bottleneck link, especially if you want to cause congestion by adjusting the clockrate downwards.

Figure 1 shows that you can do a demo with a rather minimal set of equipment. Using multiple laptops attached via a switch can help if you want to classify traffic based on IP address.

My definition of "Interesting" (as in "interesting demo") varies with speed. If you're working with a 128-256 Kbps link, forget video and stick to audio. Run some $10 handsets into FXS ports on a pair of 260Os and you can demo QoS interacting with VoIP. I've steered clear of mixing IPT (IP Telephony) and QoS demos, just due to complexity. With the VoIP approach, you can pre-configure and not have to fuss with the telephony side of things while demoing QoS. If you're working in the Tl or above range, consider video.

For ideas, see below.

If your critical application is TCP-based or Web-based, there's a way to make QoS impact visible there too. see below ("Web.")