NWC | Feature | Infrastructure | Does QoS Deliver? |

NEWS BLOGS FORUMS NEWSLETTERS RESEARCH EVENTS DIGITAL LIBRARY CAREERS

IMMERSE YOURSELF:

Storage & Servers

F E A T U R E

Does QoS Deliver?

September 4, 2003
By Mike DeMaria

>> continued from previous page

Double Pepperoni Techniques

	Issue TOC
	Print full article
	Print this page
	Download as PDF
	E-Mail this URL
	Discuss this article
	Flame the author

	In this article
	Introduction
	Layer It On
	Double Pepperoni Techniques
	Traffic Shapers
	Executive Summary
	The LAN and WAN Of QoS
	Glossary \| Weblinks

Unlike data that goes over the Internet, LAN-only traffic can honor QoS policies across various subnets. Traffic is separated into classes, which can represent a protocol, IP range or MAC address, and flows. Most systems refer to a complete TCP session as a flow--when a Web user performs the TCP three-way handshake and HTTP transfer and then finally closes the session, all that traffic is considered part of the same flow. QoS devices sometimes apply policies to an entire class, to each individual flow or a combination of the two.

To achieve QoS, modify the ToS (Type of Service) bits. ToS is composed of 8 bits, falling between the ninth and the 16th bits of the IPv4 header. Bits 0, 1 and 2 of the ToS field may be used to indicate the relative priority of a packet (see RFC-791) on a scale of 0 to 7. Bit 3 indicates normal or low delay, Bit 4 indicates normal or high throughput, and Bit 5 indicates normal or high reliability. The RFC says a packet should use two of these three options at most. Bits 6 and 7 are reserved for future use.

There are no official guidelines for what to do with this information. Networks are assumed to drop lower priority traffic in favor of higher priority. Traffic of the same priority level cannot be differentiated further, and network control traffic (such as RIP or ICMP messages) usually occupies the highest priority, thus limiting us to an effective six levels.

Unfortunately, according to Cisco Systems, Bits 3 through 5 were not implemented consistently between network vendors (see "DiffServ -- The Scalable End-to-End QoS Model"). Even worse, RFC 1349 redefined Bits 3 through 6 a decade later by way of five classifications: minimize delay, maximize throughput, maximize reliability, minimize monetary cost or normal service. We could pick only one, and none of this guaranteed bandwidth capacity. IPv6 has dropped the ToS octet in favor of a "traffic class" octet.

Using ToS bits is often referred to as "coloring," an aging but still used reference to the bronze, silver, gold, diamond and platinum service levels offered by many service providers. ToS is still used occasionally, but rarely on the LAN.

Integrated Services, or IntServ, can provide end-to-end QoS by assuring a level of available bandwidth, so long as every router on the network is set up to support and honor IntServ. There are two QoS levels provided: guaranteed service and controlled load. The guaranteed service level assures that a set amount of bandwidth is available and that there will be no additional delay on account of queuing packets. Even if you overprovision your network, IntServ will still make sure you can meet the guaranteed service level.

Controlled load acts like traditional IP traffic on a lightly loaded network--things work on a best-effort basis, and there are no strong guarantees. Non-IntServ traffic gets the leftovers.

An end host initiates an IntServ QoS session by sending out an RSVP (Resource Reservation Protocol; RFC 2205) request. RSVP is a signaling protocol that requests a resource reservation across the network. The network will approve or reject the request, depending on whether every hop can fulfill the request. If approved, the bandwidth is reserved. Each router maintains a state table for every IntServ session. If the original sender crashes or loses connectivity, the IntServ session will time out and the reservation will be canceled.

One problem with IntServ is the need to maintain state across the entire network. This taxes routers' limited CPU and RAM resources. And, every device in a packet's path, including end nodes, must understand IntServ. In practice, IntServ has been used on small-scale networks but hasn't caught on in highly distributed or large networks because of scalability concerns.

DiffServ (Differentiated Services; RFC 2475) addresses some of the shortcomings of IntServ and ToS. DiffServ is more scalable and can work across multiple networks if implemented correctly. The first six ToS bits in an IPv4 packet, or the traffic class octet in an IPv6 packet, are referred to as the DSCP (Differentiated Services Codepoint; RFC 2474). DSCP supports as many as 64 classes.

A network will form a collection of DiffServ routers, called a "DiffServ cloud." Traffic is classified when it enters the cloud. A provider will usually negotiate with a customer and establish a service-level agreement. For example, a corporation may subscribe to a bronze, silver or gold package from an ISP. The corporation's contract will determine the DiffServ priority setting.

The biggest advantage to DiffServ is that it operates at the boundary. Once data enters the cloud, internal routers don't need to maintain QoS state information. This allows the internal routers to focus only on routing.

However, DiffServ is still unpredictable. Individual internal routers may react oddly to the ToS field or possibly alter it. There are no set standards: One provider's gold standard may be another's bronze. Thus, while you may be paying for the best service, your ISP's peering agreement may say otherwise. Because DiffServ works by dropping packets selectively during high saturation periods, lowest-class members could lose connectivity completely for several seconds during bursts.

DiffServ works well on a larger LAN or WAN because it has a lower overhead and is more scalable than IntServ. Because DiffServ classification is done at the entrance to the cloud, end nodes and intermediate routers don't need to understand or set DiffServ bits.