Republished with permission from
WatchGuard Technologies, Inc.
Quality of Service (QOS) and the Vclass Firewall
by David M. Piscitello, President, Core Competence, Inc.
Internet access bandwidth is a recurring and expensive outlay for most organizations, regardless of whether you use DSL, Frame Relay/ATM, or dedicated access circuits such as DS1/E1 and DS3/E3. In a previous column, I explained several techniques the Internet research community invented to manage and optimize Internet access bandwidth usage. In this column, I'll discuss QOS techniques available on Watchguard Vclass firewalls for optimizing bandwidth use. These techniques include:
· Weighted Fair Queuing
· Type of Service (ToS) Marking
· Port Shaping.
If you'd like more information about these advanced networking methods, read on.
Weighted Fair Queuing
Weighted fair queuing provides a way to allocate more bandwidth to some types of traffic than others. By assigning a Bandwidth Weight in a security policy, you specify the amount of available bandwidth the sources and destinations associated with this policy are to receive, relative to your other policies. Let me unpack that sentence by explaining what I mean by sources and destinations, then bandwidth weight.
Sources and destinations of data streams refers to traffic that arrives at a Vclass appliance for processing. The Vclass appliances offer considerable flexibility with respect to identifying sources and destinations, which can be:
· Individual IP addresses (for example, a server delivering a streaming service)
· IP address groups (for example, all the IP addresses of a Web server farm)
· Entire subnets (identified by an IP network number and associated subnet mask; for example, the IP network and mask of a branch office).
You can also specify an incoming interface (private, public, DMZ) for your policy; in this case, the Vclass appliance will apply the policy to all traffic arriving on this interface. Interfaces can optionally be further subdivided into Virtual LANs.
In some deployments, organizations may want to allocate bandwidth according to traffic type and application. If, for example, you have a latency-sensitive application like voice over IP, you may want to guarantee bandwidth for this application regardless of which computers (and how many computers) use it. To accommodate this requirement, Vclass firewalls allow you to identify data stream sources and destinations by network protocols and well-known TCP/UDP port numbers.
Bandwidth Weight is an integer (1 to 100) that represents the bandwidth commitment for a traffic type identified in a given security policy, when network bandwidth is fully utilized. For example, suppose you want to allocate:
· 40 percent of your available bandwidth to a group of 10 hosts on your private network (10.0.0.1 – 10.0.0.10) that use IP telephony (Voice over IP),
· 20 percent to all the hosts on your private network (10.0.0.0/24) for Web access, and
· 20 percent for an FTP server authenticated users can access to retrieve files too large to be transferred as e-mail attachments.
In other words, you want twice as much bandwidth devoted to your delay-sensitive application (voice) as two other applications of equal importance. The explicit QoS actions you specify are:
In this example, policies #4 and #5 represent policies other than those for which I've specified an explicit QoS action. A default Bandwidth Weight value of 5 is assigned to, and shared across, all such policies. The relative bandwidth ratio of the three explicit and one default policy (for #4, #5) is thus 10:5:5:5. So, when available bandwidth through the Vclass appliance is fully utilized, voice traffic gets 40 percent; Web and FTP server traffic each get 20 percent; and all other permitted traffic arriving over your private interface share the remaining 20 percent.
If you want to have multiple traffic types share a Bandwidth Weight, you assign them the same QoS action. Suppose, in our previous example, we determined we wanted general Web and FTP server traffic to share a portion of the bandwidth; e.g.,
How would the QoS change? In this case, the relative bandwidth ratio for the two explicit plus the default policy becomes 10:5:5, and when available bandwidth is fully utilized, voice users will receive 50 percent of the overall bandwidth, Web and FTP server will share 25 percent, and all other policies will share the remaining 25 percent.
Even these simple examples illustrate that prioritizing network traffic can quickly become quite complicated. It's best to begin with broad prioritization policies, based on the importance of traffic types and on critical performance metrics like delay, rather than basing prioritization on constituencies. Many QoS strategies grow too complicated because they attempt to prioritize business unit or organizational needs as well as traffic types. It's hard enough to allocate the correct amount of bandwidth for voice over IP for an entire organization, much less apply the additional granularity of "allow 128Kbps for marketing, 64Kbps for engineering, and 4Kbps for janitorial services." Start with broad policies; you can always fine-tune later, once everything is working the way you want it to.
The Vclass appliance supports several kinds of ToS marking, including IP precedence and Differentiated Services Code Point (DSCP) encoding to support per-hop forwarding behavior associated with the IETF''s Differentiated Services (DiffServ) architecture. To explain the significance of this capability, let's step back and look at how DiffServ is supposed to work.
Organizations decide on a set of "differentiating" service qualities they want to make available to applications. For example, one set of service qualities might be designed to minimize delay, another to minimize deviation between delivery of IP packets (jitter), and still another set might be designed to minimize loss. A DSCP uniquely identifies each set of service qualities. The DSCP is simply a 6-bit value that can be encoded in an IP packet header. DiffServ-capable routers or switches ("hops") can classify and process a "marked" packet according to the policy represented by the DSCP value. As an example of such handling, a router may queue a packet marked with a DSCP that says, "minimize delay" ahead of earlier arriving packets with other markings. The semantics of each bit in the DSCP is defined by "the network operator" (who can be an ISP, a collaboration of organizations, or you), so the semantics can vary from network to network.
In theory, applications mark the quality of service they want to see maintained end-to-end. Deployment, however, is hampered because most operating systems and applications don't support Type of Service (TOS) marking. The Vclass appliance can modify (overwrite) the ToS byte of the IP header of traffic that matches a policy that you specify. The Vclass appliance performs ToS marking on behalf of hosts and applications: specifically, the Vclass acts as a kind of proxy that inserts DSCP values before IP packets are forwarded to a DiffServ-capable router or switch. Like Weighted Fair Queuing, ToS marking is associated with a security policy applied to sources and destinations. Firewall administrators must coordinate with routing administrators to create the correct association of DSCP to sources and destinations, and to identify the traffic direction(s), forward or reverse, where ToS marking is to be performed.
System QoS Port Shaping
Picture a large vat. A 1" diameter pipe at the bottom of the vat allows water to flow freely out. A 10" (or 100") diameter pipe at the top feeds water into the vat. If water flows unabated from the 10" (or 100") pipe, the vat will eventually overflow because a one-inch pipe can't push the water out as fast as a wider pipe can feed it in. This is analogous to the typical deployment of a two-port Internet firewall, where the private network is a 10/100 Mbps Ethernet LAN, and the company's low-cost, low-throughput, Internet access router drives a 1.544 Mbps access circuit (DS1). Now add a second and even third 10" or 100" pipe (your DMZs). In this scenario, it's easy to appreciate the benefit of applying global deceleration at your firewall, to prevent flooding your access router and access circuit.
The Vclass appliance allows you to set a limit on outgoing packets to something other than the "raw bandwidth" of the connected private interface. Thus, if you are concerned that your work force will over-utilize the available or committed rate on your Internet access circuit, you can regulate the amount of traffic originating from your private LAN by specifying a bandwidth setting for your public interface. For example, setting your public interface to 1544 Kbps tells your firewall to submit no more than 1.544 Mbps of traffic to the access router. This form of traffic enforcement can be quite important if you subscribe to a usage-based service, or one where your service level agreement imposes additional charges if you consistently exceed your committed access rate. QoS port shaping works in conjunction with WFQ; the relative bandwidth ratios you defined using the Weighted Fair Queuing are applied to the bandwidth constraint you've imposed on your private interface using QoS port shaping.
One of the classic and longest running debates in internetworking is whether to manage bandwidth or to throw excess capacity at the problem to make it go away. Whether you choose "Managed" or "BIG," bandwidth has some cost. The costs of BIG bandwidth are obvious, and appear on the recurring statements your telco sends you. Managed bandwidth exacts manpower costs associated with capacity planning and QoS engineering. Most companies try to milk the most out of Internet access circuits by implementing some traffic shaping and prioritization. The QoS toolset that Vclass offers allows you to build security and QoS policies in a single appliance, or to complement QoS techniques your routers and switches offer. Either way, remember to keep QoS policies as simple as possible. As it does in so many network and security situations, the KISS principle applies here. ##
Copyright© 2003, 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.