Another term making the rounds these days is quality of service. What are the key QoS elements that network managers should be concerned about and how should they be working toward achieving them?

Nolle: QoS is actually pretty well defined, even if everybody doesn't agree that's so. Peak and average data rate, delay and delay jitter, and discard or error rate are pretty well accepted as the key parameters. The question isn't what QoS is, it's what do you do to get it.

There are two choices; manage capacity or buy more of it. The network manager has to figure out the cost of each approach and balance them, but the manager also has to remember that resource allocation is like taxation - you've got to rob somebody to give to somebody else. That's why just buying bits per second is so attractive an option to users.

Gibbs: The Key elements of QoS are uptime - 99.99% ain't good enough for real business critical applications - and error rate. One in 1,000,000,000 bits ain't good enough for communications. Also, support, which has to be provided 365 X 24 with a maximum of 10 minutes before talking to a technician.

Heckart: This problem of defining what QoS means is going to get much worse before it gets better. Unfortunately, many service providers still think that defining meaningful QoS involves performance metrics that take a Ph.D. to understand and a protocol analyzer to prove. So what's the benefit to the end user?

Sprint has the right idea in delivering predefined service qualities that map to specific user applications. While the model can be improved upon, all the providers need to remember the KISS principle (Keep It Simple, Stupid). What most managers are concerned about is network availability (up time), response times and throughput. In some applications, like real-time voice, you can add the variation in network delay to this list.

What should concern managers most about the past definitions of QoS is the near impossibility of proving whether you're getting what's promised. The ideal provider makes the QoS easy to understand, easy to measure and includes an automated and meaningful penalty for non-delivery.

The good news with QoS is that it will help users to distinguish between different services to better understand how frame relay, Internet service, private lines, and ATM compare against each other for meeting the needs of a location or application. Today, it is hard to tell which service is really better or worse in a given area. We can make logical guesses, but there is no service QoS on each to help us validate those guesses. As QoS definitions mature and forum bodies look at setting guidelines for measurements, comparative shopping for the best value will get easier.

Briere: Achieving them? I must be one of the ones confused here. I think of QoS in a ATM/WAN type of way, where select applications have different access to different resources depending on what they are trying to do. Network managers will need more and more to quantify their needs in order to take advantage of QoS. This goes back to really understanding what each site and application requires, recognizing that no single solution is going to win out.

Kearns: To the user, QoS means 'can I do what I want, when I want to.' To the net admin that translates to access, throughput and directory services. Access - 100% uptime for all services via clustering and redundancy. Throughput - Predictable throughput, all the time, any time. Directory services - easily locatable objects and services.

Bradner: This is a very old story, going back to at least 1964 and the first discussions about the idea of doing packet rather than connection-based data networks. The traditionalists have been decrying packet-based networks ever since. For years, but thankfully no more, IBM speakers claimed that you could not build a corporate data network using TCP/IP because it is based on individually routed or switched packets rather than being connection-based and the corporate network needed QoS which they claimed would only work with connection-based networks.

There are three types of QoS that are reasonable to talk about: probabilistic QoS, where there is a high probability that there will be enough network and server resources to get the tasks done in the required time; instance of application QoS, where specific resource reservations are made for each individual IP phone call or other resource demanding application when it is run; and class-based QoS, where network uses are divided into classes and traffic for the classes is handled differently by the network. Probabilistic QoS is where most networks are today and that works quite well in bandwidth-rich campus environments. I'd vote class-based QoS as most likely to succeed and instance of application QoS as a pipedream with far too many scaling, authentication and accounting issues to succeed in the real world.

Go to the next topic...