Introduction

To completely appreciate the capabilities of the IQ Engine it is useful to understand the operation of an IP transport mechanism, such as TCP. TCP is a connection-oriented transport mechanism that relies on an established connection between a client and a server to exchange data. TCP is considered a reliable service because it requires the receiving host to acknowledge the successful receipt of data. If the sending computer fails to receive a proper acknowledgment (an ACK packet) it will resend the data.

TCP also maintains a "congestion window" that establishes how much data can be transmitted before an acknowledgment must be received. TCP will attempt to send more and more packets in the congestion window until it hits a time-out condition (no ACK packet is received within a specified period). When it hits time-out, TCP retransmits the data and reduces the congestion window by 50%. Reducing the size of the congestion window reduces the rate of transmission. The rate at which TCP increases and decreases the window size is determined by delay of data packets and the rate of arriving ACK packets. Therefore, transmission rates can be controlled by intelligently delaying packets.

The IQ Engine uses detailed packet information from the INSPECT Virtual Machine to properly classify incoming traffic. Once classified, each packet is placed into the correct per flow queue and scheduled for transmission based on the bandwidth management policy. By controlling exactly when a packet is put on the line, the IQ Engine can precisely control the overall mix of traffic. For example, a network manager can assign FTP traffic a weight of 10 and give HTTP traffic a weight of 30. During periods of congestion, the IQ Engine will transmit three HTTP packets for each FTP packet to maintain the desired 3:1 ratio.

Holding packets in queues introduces a delay that serves to throttle traffic from the sender to the receiver. With TCP traffic, the IQ Engine delays packets in order to reduce the size of the congestion window. This causes the sender to decrease its rate of transmission to meet the parameters defined in the bandwidth policy. Using this feedback mechanism, the IQ Engine can accurately control the bandwidth consumption of one or more connections without dropping or discarding packets.

The IQ Engine also implements a Retransmit Detection Early Drop (RDEC) algorithm to eliminate TCP retransmit storms by preventing redundant retransmits from hitting the line. With this algorithm, FloodGate-1 can reduce the number of retransmits by as much as 98% and dramatically improve line efficiency.

Virtually all IP-based application traffic has some form of end-to-end handshaking and throttling. In fact, applications that lack throttling mechanisms cannot function over IP lines. Although their methods differ, all streaming protocols (e.g., RealAudio, RealVideo, VDOlive, NetMeeting) employ some means of fitting their transmission rates to the available bandwidth. While an application may attempt to send more data than is allowed, such bursts will be delayed and smoothed by FloodGate-1's packet scheduler. This has the effect of pushing back on the traffic and forcing it to fit within the bandwidth allocation established by the management policy. By intelligently delaying packets, FloodGate-1’s IQ Engine can effectively control the bandwidth of all IP-based traffic.

The IQ Engine controls the allocation of bandwidth dynamically and responds immediately to changing traffic conditions. The IQ Engine’s packet scheduler is preemptive, guaranteeing that high priority traffic is always given precedence over lower priority data. Exceptional accuracy is achieved even when allocating bandwidth based on large weighted priorities, such as a 50:1 weighting between two Internet applications. In addition, because packets are always available for immediate transmission the IQ Engine ensures that bandwidth is 100% utilized when it counts the most, during periods of congestion.

Check Point’s patented Stateful Inspection technology provides the IQ Engine with complete application-layer information. This application-layer awareness allows the IQ Engine to discriminate between different Internet services, even when they are using the same port. For example, FloodGate-1 can distinguish between PointCast, Microsoft CDF, NetCaster, and normal Web traffic, even though all use TCP port 80. Many bandwidth management products, however, lack application-layer information and treat all applications using a common port identically.

In addition, complete application-layer awareness allows the IQ Engine to parse URLs and set unique priority levels. This is important considering that more than 30% of all downloads are carried out via HTTP rather than FTP. With FloodGate-1, downloads with *.exe or *.zip extensions can be identified within the bandwidth policy and assigned specific bandwidth privileges.

Another means of controlling bandwidth for TCP traffic is by modifying the window size advertised by the receiver. In each acknowledgment packet, the receiver advertises the number of bytes that it can currently handle. This provides direct feedback to the sender of how much data to send. By intercepting these acknowledgment packets and decreasing the advertised window size, the sender is tricked into thinking that the receiver has less capacity than it really does. The sender is then forced to reduce its transmission rate.

TCP window-sizing is effective for smoothing connections and improving the quality of service for individual connections. However, it provides an extremely inefficient means of controlling the mix of traffic on a congested line and results in a large amount of wasted bandwidth. The basic reason for this inefficiency is the fact that window size manipulation signals the TCP end-points to slowly increase or decrease their rate of transmission. Because this signaling requires one or more Round Trip Transmissions (RTTs), transmission rates cannot be changed rapidly enough to keep pace with real world traffic conditions.

There are two problems caused by the RTT lag time problem described above.

1. Unused Bandwidth

When an existing connection terminates, its bandwidth becomes available to other users and should be immediately redistributed among other active connections. However, once this bandwidth is detected the bandwidth manager must wait for the next ACK packet for each of the active connections and then increase the advertised window size. When the modified ACK packets arrive at each sender, the sender will send more data in an attempt to utilize the bandwidth that it was allotted.

The lag time incurred during these TCP manipulations creates an average RTT of 1.5, which means bandwidth is unused while the system is trying to respond. When connection mixes are relatively stable, this bandwidth penalty may be tolerable. However, during real world traffic conditions where HTTP connections average only 6 Kbytes in length, the traffic mix changes very rapidly. Using TCP window size manipulation generates an extreme amount of wasted bandwidth.

2. Inability to Promptly Meet Guarantees

When a new connection is established that is entitled to either guaranteed bandwidth or a high priority, there is substantial lag time between the time the connection requires the bandwidth and the time the bandwidth is made available. Since other lower priority traffic may be using the line when the new connection arrives, these connections would have to be told to slow down via manipulation of the advertised TCP window size. Again, an average RTT of 1.5 creates slow response times.

The only alternative to the lag time problem described above is to reserve a fixed amount of bandwidth that is always available to high priority or guaranteed connections. Unfortunately, this reserved bandwidth would be unavailable to all other traffic, even when there are no high priority connections. This approach is inefficient and results in wasted bandwidth.

Routers do not have any application-layer awareness of incoming traffic. They are, for example, unable to discern normal Web traffic (TCP port 80) from PointCast Traffic (TCP port 80). Also, they cannot follow complex protocols, such as FTP, RealAudio, and VDOlive. Without this critical application-layer information routers cannot effectively control the overall mix of traffic.

In addition, routers provide no direct feedback mechanism to throttle traffic. They simply discard packets when the line becomes congested.