Republished with permission from WatchGuard Technologies, Inc.


Introducing Quality of Service

by David M. Piscitello, President, Core Competence, Inc.

Four vehicles, heading southbound on Route 95, arrive at a section of the Interstate where the highway narrows from four, to three, then ultimately two lanes. The four vehicles competing for these two lanes are:

  • A medical courier van delivering a heart for surgery;
  • A fire truck, on the way to a four-alarm blaze;

  • An armored car carrying $200 million, to be delivered to a Federal Depository;

  • Four good ol' boys in an SUV headin' fer a weekend of huntin' and fishin'.

Now let me pose a few questions. Answers to these questions would provide a basis for quality of service for automobile traffic: Are these vehicles equally important? Which vehicle should proceed first? Which should have a guaranteed priority along its entire route? Which might have a route that takes a pre-determined amount of time? If one had to be removed from the highway to allow others to proceed, which should we choose?

We can apply similar thought processes to Internet application traffic.

What is Quality of Service?

The Internet operates on a packet switching "best effort delivery" service provided by Internet Protocol (IP). Quality of Service (QoS) refers to functions applied to provide preferential treatment or "better than best effort delivery" to certain applications. QoS functions attempt to control how applications use and share bandwidth. When real time applications are used, QoS functions can control performance metrics such as inter-packet arrival times (jitter), delay in packet delivery (latency), and packet loss.

Basic QoS operations deal with the age-old problem of supply and demand as it relates to bandwidth, memory, and packet processing. Every network element (router, switch, firewall, or any IP forwarding device) has finite resources. Every communications link (Ethernet LAN, Frame Relay circuit, T1 access circuit) has finite bandwidth. When we can match supply to demand, normal "best effort delivery" works extremely well. A campus of 100 Mbps LANs connected by switches with ample memory and CPU can typically support the diverse traffic generated by hundreds of hosts connected to these LANs.

However, when we forward traffic from these LANs onto a 1.544 Mbps Internet access circuit, we encounter the networking corollary to electrical impedance. The bandwidths don’t match. At some point, considerably more traffic may arrive than can be immediately forwarded across the access circuit. During the onset of congestion, the IP forwarding device typically stores, or queues, arriving packets while processing packets that arrived first. But queuing capacity is a function of (finite) memory at hand. If the arrival rate continues to exceed the forwarding rate, memory will eventually be exhausted, and the IP forwarding device must discard packets to prevent failing entirely (referred to as congestion collapse).

Queuing and discarding packets indiscriminately can have detrimental effects on application performance, user experience, and productivity. Consider our four vehicles. Queuing – waiting in traffic – jeopardizes the heart transplant patient and hampers fire fighting. Delaying the armored car on a time-sensitive schedule may cause law enforcement to dispatch patrol cars. And clearly, denying passage to the ambulance or fire engine in favor of the SUV is a Bad Result.

Just as laws help us prioritize automobile traffic, IP traffic handling rules, supported by queuing and selective discard mechanisms, help us prioritize application traffic so that time-sensitive and business critical applications can take priority when demands exceed resources.

Tools of the "Edge" QoS Trade

Edge QoS refers to several different traffic-handling techniques, including traffic shaping, traffic policing, and traffic marking. Let's consider each of these concepts.

Traffic Shaping

The basic first in, first out (FIFO) queuing method keeps congestion at bay, but FIFO has no prioritization or fairness properties. Ideally, we should be able to identify which packets to discard when necessary. We might also want to reserve resources that applications of equal importance can share so that one does not run at the total detriment of the other. Or we might want to weigh application priority, then apportion resources accordingly. These needs can be met by many other queuing or traffic shaping techniques.

Strict Priority Queuing (a.k.a., priority queuing with starvation) assigns a priority (for example, high, normal, low) to traffic, classified by protocol, packet size, source and destination addresses, and ports. High priority traffic gets absolute preferential treatment over lower priority traffic, to the extreme that low priority traffic may get no bandwidth whatsoever during peak utilization periods. A less severe form of priority queuing allows minimum bandwidth guarantees for all priorities. With this form of queuing, you can allocate some bandwidth to all Intranet traffic (traffic forwarded to any of your offices), leaving the remainder for general Internet use (traffic to any other destination).

Most priority queuing methods treat all packets as equals, regardless of size. This is less than ideal when you mix short packet applications like Telnet, real time applications like Voice over IP (VoIP), and large download applications like Web browsing. For example, the transmission time for a 1500 byte HTTP packet can exceed the desired inter-packet arrival for smaller VoIP packets. Simply put, you can’t control jitter and delay using priority queuing alone. Such situations call for a Weighted Fair Queuing (WFQ) method that allocates resources in a more granular manner, e.g., in bytes rather than packets [described as far back as 1989; see Reference 1 at the end of this article]. With WFQ, you can say, "allow ten 100-byte VoIP packets for every one 1500 byte HTTP packet." WFQing can assure more predictable delivery (e.g., bounded delay) and can prevent bandwidth starvation for low priority traffic. For example, you can say, "On my 1.544 Mbps T1 access circuit, interoffice HTTP can use up to 600 Kbps of bandwidth, interoffice VoIP can use 400 Kbps, and the remainder can be used by any other service."

Traffic Policing

Traffic Policing complements traffic shaping. Policing is similar to traditional firewall packet filtering. Whereas packet filtering drops packets that violate security policy, to prevent unauthorized use of services, traffic policing drops packets that violate a bandwidth management policy, to prevent applications from hogging resources.

How does discarding packets help? TCP, the reliable transport service most Internet applications use, includes a rate control mechanism that reacts to packet loss by employing congestion avoidance and control measures [for details, see Reference 2 at the end of this article]. TCP-based applications experiencing loss start submitting packets at a slower rate to relieve congestion, gradually increasing submission rate as congestion is avoided.

Packet discard is a by-product of queuing. Most methods use "tail drops," which means they discard the last packet received (in the lowest priority queue) first. An approach called RED (Random Early Discard) is a fairer discard method that leads to better network utilization and application behavior, but that's a complex topic best left for another article.

Traffic Marking

Thus far, we have discussed techniques that you can apply at one location where you hope to milk the most out of your access circuit (and thus avoid buying more bandwidth). Even more robust QoS and traffic engineering mechanisms can be implemented when applications indicate desired service characteristics as they submit data. Today, individual applications can do this by using the Differentiated Services encoding (DS) in the IP Type of Service (TOS) field.

This encoding specifies a per-hop behavior or treatment that network elements (routers, switches) apply when forwarding a "DS-marked" packet. Markings give one IP forwarding device the ability to tell another device how it should treat this packet, with respect to other packets that device is processing. This allows all IP forwarding devices in a given domain to prioritize and discard traffic with the same traffic policy and constraints.

The Differentiated Services (DiffServ) architecture (RFC 2475) recognizes that upgrading every application and operating system to use the DS field is no small undertaking. Therefore, an intermediate system can overwrite the DS field of packets with Differentiated Services Code Point values before forwarding them to a DiffServ-capable router or switch.

But What Does QoS Have to Do With Firewalls?

Firewalls are one network element where you can implement traffic shaping, policing, and marking. The Firebox Vclass models support several methods of traffic shaping:

  1. Rudimentary port shaping policy enforcement to prevent traffic emanating from the private port (trusted network) from flooding an access router;
  2. Relative bandwidth allocation using weighted fair queuing techniques to prioritize traffic across sources and applications; and

  3. Type of Service marking of packets so DS-capable access routers can process them.

In a future column, we’ll discuss how these Vclass features can be used to manage QoS at your edge of the Internet. For now, I'll conclude by saying that, basically, a Vclass firewall helps keep Bubba's leisurely fishing trip from blocking your ambulances and fire trucks. And if Bubba were a network administrator, he'd tell you that for those peak times when demand outstrips available resources, these QoS features are "better'n grits." ##

Reading Assignments

[1] "Design and Analysis of a Fair Queuing Algorithm," by A. Demera, S. Keshav, and S. Shenker, ACM SIGCOMM'89, Austin, September 1989.

[2] "Congestion Avoidance and Control," V. Jacobson, Computer Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988.

[3] "Quality of Service in the Internet: Fact, Fiction, or Compromise?," Paul Ferguson, Jeff Huston 

Copyright© 2002, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.

Copyright © 1996 - 2002 WatchGuard Technologies, Inc. All rights reserved.