The QoS Dilemma

The problem with IP is that, like Ethernet, it is a connectionless technology and does not guarantee bandwidth.  Specifically, the protocol will not, in itself, differentiate network traffic based on the type of flow to ensure that the proper amount of bandwidth and prioritization level are defined for a particular type of application. By contrast, the cell-based ATM standard incorporates such service requirements in its specifications. Because IP does not inherently support the preferential treatment of data traffic, it’s up to network managers and service providers to make their network components aware of applications and their various performance requirements.

Internet Protocol (IP) based networks provide “best effort” data delivery by default.

Best-effort IP allows the complexity to stay in the end-hosts, so the network can remain relatively simple. This scales well, as evidenced by the ability of the Internet to support its phenomenal growth. As more hosts are connected, network service demands eventually exceed capacity, but service is not denied. Instead it degrades gracefully. Although the resulting variability in delivery delays (jitter) and packet loss do not adversely affect typical Internet applications (email, file transfer and http/Web applications) – other applications cannot adapt to inconsistent service levels. Delivery delays cause problems for applications with real-time requirements, such as those that deliver multimedia, including two-way applications like VoIP telephony services.

Quality of Service (QoS) generally encompasses bandwidth allocation, prioritization, and control over network latency for network applications. There are several ways to ensure QoS, no matter what type of network you’re talking about – Ethernet or ATM, IP or IPX.

The easiest one is simply to throw bandwidth at the problem until service quality becomes acceptable. This approach might involve upgrading the backbone to a high-speed technology such as Gigabit Ethernet or 622Mbit/sec ATM. If you have fairly light traffic in general, more bandwidth may be all you need to ensure that applications receive the high priority and low latency they require.

However, this simplistic strategy collapses if a network is even moderately busy. In a complex environment – one that has a lot of data packets moving in many paths throughout the network, or that has a mixture of data and real time applications – you could run into bottlenecks and congestion.

Increasing bandwidth is a necessary step for accommodating these real-time applications, but it is still not enough to avoid jitter during traffic bursts. Even on a relatively unloaded IP network, delivery delays can vary enough to continue to adversely affect real-time applications. To provide adequate service – some level of quantitative or qualitative determinism – IP services must be supplemented. This requires adding some “smarts” to the net to distinguish traffic with strict timing requirements from those that can tolerate delay, jitter and loss. That is what Quality of Service (QoS) protocols are designed to do. The goal of QoS is to provide some level of predictability and control beyond the current IP “best-effort” service.

QoS does not create bandwidth, but manages it so it is used more effectively to meet the wide range or application requirements.

Simply adding bandwidth doesn’t address the need to distinguish high-priority traffic flows from lower-priority ones. In other words, all traffic is treated the same. In the network realm, such egalitarianism is not good, because network traffic is, by its nature, unpredictable. For instance, on some days, you’ll see traffic bursts occurring at 8 a.m., while on other days you’ll see them at noon or at the end of the day. These traffic bursts can move around too. One day, your Internet gateway or one of your switches is the bottleneck; another day, it’s your intra-campus video conferences or heavy voice traffic causing the congestion.

Additional bandwidth can solve some of your short-term problems, but it’s not a viable long-term solution.

Particularly if you already have enough bandwidth to accommodate all but the most highly sensitive network applications.

How can you flag special traffic as high priority on an IP network? Options like Resource Reservation Protocol (RSVP), multiple flows, and tagging fields can help you give sensitive applications the resources they need.

A number of QoS protocols have evolved to satisfy the variety of application needs. We describe these protocols individually, then describe how they fit together in various architectures with the end-to-end principle in mind. The challenge of these IP QoS technologies is to provide differentiated delivery services for individual flows or aggregates without breaking the Net in the process. Adding “smarts” to the Net and improving on “best effort” service represents a fundamental change to the design that made the Internet such a success. The prospect of such a potentially drastic change makes many of the Internet’s architects very nervous.

To avoid these potential problems as QoS protocols are applied to the Net, the end-to-end principle is still the primary focus of QoS architects. As a result, the fundamental principle of “Leave complexity at the ‘edges’ and keep the network ‘core’ simple” is a central theme among QoS architecture designs. This is not as much a focus for individual QoS protocols, but in how they are used together to enable end-to-end QoS.

Brief overview of each of the key QoS protocols

There is more than one way to characterize Quality of Service (QoS). Generally speaking, QoS is the ability of a network element (e.g. an application, a host or a router) to provide some level of assurance for consistent network data delivery. Some applications are more stringent about their QoS requirements than others, and for this reason (among others) we have two basic types of QoS available:

Resource reservation (integrated services): network resources are apportioned according to an application’s QoS request, and subject to bandwidth management policy.

Prioritization (differentiated services): network traffic is classified and apportioned network resources according to bandwidth management policy criteria. To enable QoS, network elements give preferential treatment to classifications identified as having more demanding requirements.

Applications, network topology and policy dictate which type of QoS is most appropriate for:

Individual flows (Per Flow): A “flow” is defined as an individual, uni-directional, data stream between two applications (sender and receiver), uniquely identified by a 5-tuple (transport protocol, source address, source port number, destination address, and destination port number).

or Aggregates:  An aggregate is simply two or more flows. Typically the flows will have something in common (e.g. any one or more of the 5-tuple parameters, a label or a priority number, or perhaps some authentication information).

To accommodate the need for these different types of QoS, there are a number of different QoS protocols and algorithms:

ReSerVation Protocol (RSVP): Provides the signaling to enable network resource reservation (otherwise known as Integrated Services). Although typically used on a per-flow basis, RSVP is also used to reserve resources for aggregates (as we describe in our examination of QoS architectures).

Differentiated Services (DiffServ): Provides a coarse and simple way to categorize and prioritize network traffic (flow) aggregates.

Multi Protocol Labeling Switching (MPLS): Provides bandwidth management for aggregates via network routing control according to labels in (encapsulating) packet headers.

Subnet Bandwidth Management (SBM): Enables categorization and prioritization at Layer 2 (the data-link layering the OSI model) on shared and switched IEEE 802 networks.

Thanks to Yee-Ting Li from High Energy Particle Physics, Dept. of Physics & Astronomy (London, UK). His homepage and great QoS article.