The quality-of-service quandary

I n our last column we started to list the questions we get asked most frequently by end users about virtual private network services.

A big question that is often asked deals with how quality of service (QoS) will be implemented and how granular it will be.

TeleChoice defines QoS as the ability of a service to define delay, jitter, cell/packet loss ceilings, security and bandwidth on an application-by-application basis. Ideally, you want to be able to strictly define how to route and treat a call.

That's QoS.

Unfortunately, the industry is nowhere close to this definition today. QoS offerings are extremely basic. A lot of people are working to make it better, but no one is totally sure how our ideal will be implemented. Will QoS implementation occur through IPv6? Or through ATM?

To get the skinny on IPv6 we called our friend Mark Miller at DigiNet, who wrote the book "Implementing IPv6."

Miller said the IPv6 packet header has two fields that relate to QoS: Class (8 bits) and Flow Label (20 bits). The Class field is intended to distinguish between different priorities or classes of packets. The Flow Label field is used by a source to label packets that require some special handling, such as real-time service.

However, at this time, definitions for how to use these fields are still under development. And the Internet community is still researching how flows of these packets at Layer 3 relate to flows of frames or cells at Layer 2, and how both of these fields relate to the upper-layer application requirements.

As for ATM, it only defines four classes of service (CoS). Talk about needing more granularity!

This has been our gripe about ATM CoSes since the beginning. None of these four CoSes is very good for real applications - voice or data. This is despite the fact that ATM is supposed to be good at supporting many applications simultaneously.

What is needed is a combination of Unspecified Bit Rate (UBR) and Variable Bit Rate, or UBR and Available Bit Rate. In other words, something cost-effective, with guaranteed min-imum bandwidth and sustained bursting capability when bandwidth is available.

But this isn't enough to meet our ideal definition for QoS. Within any given CoS, users need the ability to define dozens of layers, such as prepackaged service contracts, specifying delay, relative and/or absolute priority, discard ratios, etc. Some vendors provide this through proprietary extensions, but that doesn't help outside of a closed network.

The good news is that the Internet Engineering Task Force had another plenary meeting in Los Angeles recently and is working on defining this. (If you want to know what's happening in detail, check out the IPv6 industry Web site for minutes of the IPng Working Group meeting: http://playground.sun.com/ipng).

In the short term, you'll see QoS implemented using priority technologies on closed networks, such as a closed IP, frame relay or ATM network.