FloodGate-1

Limitations of Standalone QoS Devices
When a dedicated QoS device is positioned on the WAN side of the VPN/Firewall device, it cannot effectively classify traffic for several reasons (see figure below):

	The QoS device cannot classify traffic based on information in the IP header, because the information is encrypted. Example: encrypted e-mail will receive the same priority as encrypted TN3270, because the QoS device cannot differentiate between the two services.
	The QoS device cannot classify traffic destined for specific users or servers. This is because the device relies on the destination IP address to classify traffic, but NAT sends inbound traffic to the firewall's IP address.
	The QoS device cannot classify traffic originating from specific users or groups. This is because the device "sees" the entire internal network as a single IP address. NAT hides all internal IP addresses behind a single, public, IP address. Example: traffic from the engineering group cannot be differentiated from that of the finance department.
	The QoS device is unprotected by the Firewall device, and therefore can be subject to Denial of Service attacks.

QoS Device on WAN Side of VPN/Firewall

When a standalone QoS device is positioned on the LAN side of the VPN/Firewall device, QoS management decisions are inaccurate and less effective for a number of reasons (see figure below):

	The QoS device cannot prevent unacceptable levels of traffic congestion on the outbound Internet link. This is because the QoS device attempts to manage Internet link's total available bandwidth (45Mbps), but VPN overhead causes the actual traffic load to grow beyond 45 Mbps.
	The QoS device cannot "see" or manage traffic flowing to and from the public servers located on the DMZ.

QoS Device on LAN Side of VPN/Firewall

Integrated QoS/VPN Solutions
FloodGate-1/VPN-1 solutions integrate QoS, VPN and firewall functionality on the same device, and do not experience the problems described above. Shared access to IP header, encryption, NAT, and DMZ information enables FloodGate-1 to account for all relevant information in its control algorithm (see figure below):

Integrated QoS/VPN/Firewall Device

In summary, non-integrated solutions cannot accurately control traffic because they do not have access to all of the relevant information. Integrated solutions are the only option for secure network environments.

Although per connection controls can be useful in some situations, it is much more important to allocate bandwidth by traffic class during periods of network congestion. For instance, instead of controlling the bandwidth for each connection, the network manager should be able to define how much total bandwidth is granted to ALL.MP3 file downloads, or to the entire engineering group. Controlling bandwidth in aggregate is vital to defining a management policy that reflects the overall priorities of the organization.

Some products provide partitions, which assign a fixed percentage of the line to a specific application. Partitions, however, are both inflexible and wasteful. First, if a class of traffic belongs to a partition it cannot utilize available bandwidth outside the partition. Also, if bandwidth belonging to a partition is sitting idle it cannot be used by other traffic. For these reasons partitions should be avoided.

Bandwidth can be controlled by simple mechanisms such as guarantees and limits. However, priorities provide the most powerful and flexible method to dynamically allocate limited bandwidth. The objective of priorities is to grant preferential privileges to one class of traffic over another. For example, a network manager could grant a higher bandwidth priority for Web traffic than SMTP traffic.

There are two types of bandwidth priorities: absolute and weighted. Absolute priorities force network managers to assign a priority level to each class of traffic. For example, if there are seven priority levels available, Web traffic may be given a priority of 7, and SMTP traffic assigned a priority of 6. Absolute priorities are inefficient because they operate on an "all-or-nothing" basis. When the line is oversubscribed, ALL higher priority traffic gets through before ANY lower priority traffic receives bandwidth. As a result, heavy Web usage may deny bandwidth to all SMTP connections. This situation is defined as bandwidth starvation. QoS devices should NEVER block connections by denying bandwidth. Blocking traffic is the job of a firewall, not a QoS device.

FloodGate-1 uses weighted priorities to allocate available bandwidth based on relative merit or importance, without starvation. When using weighted priorities, each class of traffic is given a weight that is relative to all other weights defined in the management policy. The weights define the basis upon which traffic competes for available bandwidth.

For example, Web traffic can be assigned a weighted priority of 60, and SMTP traffic can be given a weight of 20. When bandwidth resources are oversubscribed, FloodGate-1 ensures that the ratio of Web traffic to SMTP traffic is accurately maintained at a 60:20 ratio. FloodGate-1 allows an unlimited number of priorities to be set so that even the lowest priority traffic receives a portion of the available bandwidth. Weighted priorities provide the only means to prioritize traffic and prevent starvation.

As explained previously, absolute priorities should not be used because they cause bandwidth starvation and block traffic. If a QoS device does not support weighted priorities, the only available method to allocate bandwidth is guarantees. Unfortunately, bandwidth guarantees are an impractical solution because they can only be used to meet worst-case traffic conditions.

For example, if an organization is supporting 100 users they must plan for the worst-case situation in which every user is simultaneously vying for network bandwidth. If guarantees were set to account for only 50 concurrent users, then the 51st user would be denied bandwidth and their connection would be blocked. As stated earlier, QoS devices should never block traffic.

Setting guarantees for all 100 users may effectively address the worst-case condition, but it is necessary to examine what happens during nominal conditions when fewer than 100 users are competing for bandwidth. Let's assume that an organization has a T1 link (approximately 1.5 Mbps) to the Internet and, for simplicity, all users are deemed to have equal bandwidth priority. In this situation, each of the 100 users would be guaranteed approximately 15 Kbps of bandwidth.

If only 40 users are requesting bandwidth, then 600 Kbps (40 users X 15 Kbps/user) of bandwidth is set aside to meet guarantees. The remaining 900 Kbps, however, goes completely unmanaged. A QoS device should never leave a portion of the line unmanaged. If it does, then it is failing to provide a complete solution to the congestion problem.

Weighted priorities obviate the need to specify guarantees meeting worst-case traffic conditions. To manage traffic dynamically under all conditions a QoS device must provide weighted priorities as a bandwidth control mechanism.