Often used indiscriminately, quality of service is the nexus where Bellheads and Netheads finally meet.

By Rob Howald
CommsDesign Feb 03, 2003

Editor's note: To view a PDF version of this article, click here.

Not long ago, quality of service was something phone company engineers—Bellheads—cared most about, while Netheads scoffed at such outdated ideas. Now, as the poles of network infrastructure battle for the minds and dollars of tomorrow's networks, QoS is at the crux of the debate. This month, we will discuss the metrics encompassed by QoS.

In early December 2002, I attended one of the major cable industry trade shows. With attendance down about 40 percent, it had all the energy of a Bob Dole presidential campaign.

The show's first evening, our company, Motorola Inc., had a dinner reservation at one of Anaheim's finest restaurants serving French cuisine—that's French cuisine, not french fries. Unfortunately, due to the dearth of customers to schmooze in the business area's corner of our booth, the dinner ended up being for all Motorola employees.

Being the responsible employees we are—and not just because the GM was part of the crowd—we changed the reservation to a Mexican restaurant the local guide told us was "best of Anaheim." Now, I love Mexican food, and this Mexican food was indeed excellent. The atmosphere-well, let's just say it was strip-mall chic and definitely a cut above the laundromat next door. Given the change in venue—and menu—our bill at the end of the meal was surely a small fraction of what the original plan would have yielded.

Despite our penny-pinching ways, the food indeed turned out to be very good. But what about the "best of Anaheim's" QoS? What can we say about the service experienced at budget burritoville? As every wait staffer quickly figures out with business customers, when serving rounds of drinks, the delivery of the meal can be delayed almost indefinitely. Not only that, but as time and bottles go by, diners become less and less concerned about the delay. This delay time would be quantified and described in networking circles as latency.

When the nachos finally ran low, the service providers realized the main course would have to be delivered soon, so they placed our order with the kitchen staff. Soon thereafter, the plates began to be served. Unfortunately, there were about 15 of us, and only one cook and one server. The food delivery was thus sporadically timed, as the server brought out the dishes as they rolled off the grill in sequence. Over the course of five or 10 minutes, three dishes would arrive, then a short wait, then two more, another wait, then another couple, etc. This variation in consistency of delivery is what network weenies would call jitter. This term is perhaps the most confusing one, because it has meaning as both a Layer 1 and Layer 2 parameter. Physical layer (Layer 1) gurus use "jitter" for a similarly critical, but different metric.

Finally, guess whose meal they forgot altogether? Had they known I was a rich and famous contributor to CSD—well, famous anyway—I'm sure this would not have happened (OK, at least a contributor to CSD). After delivering 14 meals to everyone around me, the server asked what I had ordered. I repeated my order, and the server ran to the chef, who started right in on it. This, in networking lingo, is simply data loss.

This month, in addition to offering my dining critique—three-and-a-half stars out of five, but skip the salad—we will dive into one of the key concepts of converging networks—QoS—and discuss what it represents.

That was Then
The current situation in network mindsets is the well-documented conflict that boils down to diehards associated with the telephony infrastructure and those associated with the data infrastructure. Carefully designed and implemented telephone networks were developed with rigor and rigidity. Ethernet-based local and wide area networks are built around flexible, low-cost, best-effort data service. The challenge of the former is to pass data efficiently and cost-effectively—as a LAN can. The challenge for the latter is to obtain some, most or all of the rigorous capabilities offered originally in telephone networks and that we now broadly categorize as "high-QoS" networks.

Precisely what parameters do we mean by "QoS"? People seem to hurl the term around with impunity these days, often without making their meaning clear. QoS is more than just "good" service—whatever that means—and typically boils down to five interrelated parameters, three of which and a couple of Corona's defined my evening out at the Anaheim Mexican restaurant. While interrelated, the five are also independently quantifiable metrics, and their relationship often amounts to trading one off against another.

There are the three that, along with digestive concerns, may come with your refried beans and nachos: latency, jitter and packet loss.

But the two items that find their way into QoS discussions, whether generally considered QoS parameters or not, are availability (i.e. the "five nines" definition of "carrier class") and throughput-usually a bit-per-second number.

Availability is generally more an architecture and cost issue, and less a technology one. Simply put, availability speaks to how often the network is "up" and thus available for service carriage. Carrier class, if going by the definition of 99.999 percent available, works out to a little more than five minutes a year of down time. You can understand, from just this one QoS parameter, why testing high-QoS solutions could itself become a significant part of a qualification process.

Of course, when considering the two polar end points of the service possibilities—voice and best-effort data—things are not always clear-cut. An IP network will route packets around downed network segments in a flexible and reliable manner, but likely without maintaining the same performance as if all network segments were functioning. But, if it is nonguaranteed traffic with no predefined minimum throughput, it is still "good enough" in terms of the service quality promised. It is easy to see how including multiple data service and quality tiers only leads to more fuzziness. Nonetheless, availability corresponds to what percentage of time the network is up—with what constitutes "up" sometimes difficult to pinpoint.

Now, let's move on to throughput. Throughput is often associated simply with increasing the bits per second as technology enables it, which stirs little controversy. As a physical last-mile link issue, it is simply always preferable to be able to offer more bandwidth at the largest bottleneck. This is as simple as the cable modem vs. the dial-up line.

However, bandwidth vs. traffic engineering is an argument that can stoke the flames of debate. Simplified QoS advocates will argue that the best way to ensure QoS is to build a super-big pipe, one in which the allocated traffic is merely a small part of what the pipe can handle. The idea, obviously, is that no one will be contending for network resources; everyone will get virtually all the throughput they want, and packets will traverse the network at nearly wire speed. QoS follows by default. Netheads who speak Internet Protocol (IP) would be especially attracted to this scenario, particularly because LAN equipment has ridden impressive cost curves, providing access to cheap bandwidth.

The opposite angle would be that it is senseless not to attempt to optimize or at least efficiently use a key valuable resource such as bandwidth. It is ill-advised to assume that underutilization will always be possible and that it will be an adequate approach. In this view, super pipes are merely the lazy man's traffic engineering. Since the modem scenario mentioned above is often played out in practice—a key bottleneck limits end-to-end throughput—it makes sense to design for throughput optimization at some level. Thus, throughput as a QoS term can stir a bit of controversy.

Latency, Jitter, and Loss
The three QoS parameters of latency, jitter and loss are depicted in Figure 1.