Product Documentation

Speed Optimizations

Jan 03, 2013

Most TCP implementations do not perform well over WAN links. To name just two problems, the standard TCP retransmission algorithms (Selective Acknowledgments and TCP Fast Recovery) are inadequate for links with high loss rates, and do not consider the needs of short-lived transactional connections.

CloudBridge implements a broad spectrum of WAN optimizations to keep the data flowing under all kinds of adverse conditions. These optimizations work transparently to ensure that the data arrives at its destination as quickly as possible.

WAN optimization operates transparently and requires no configuration.

WAN optimization is a standard feature on all CloudBridge appliances.

The figure below shows the transfer speeds possible at various distances, without acceleration, when the endpoints use standard TCP (TCP Reno). For example, gigabit throughputs are possible without acceleration within a radius of a few miles, 100 Mbps is attainable to less than 100 miles, and throughput on a worldwide connection is limited to less than 1 Mbps, regardless of the actual speed of the link. With acceleration, however, the speeds above the diagonal line become available to applications. Distance is no longer a limiting factor.

Figure 1. Non-accelerated TCP Performance Plummets With Distance

Note: Without Citrix acceleration, TCP throughput is inversely proportional to distance, making it impossible to extract the full bandwidth of long-distance, high-speed links. With acceleration, the distance factor disappears, and the full speed of a link can be used at any distance. (Chart based on model by Mathis, et al, Pittsburgh Supercomputer Center.)

Accelerated transfer performance is approximately equal to the link bandwidth. The transfer speed is not only higher than with unaccelerated TCP, but is also much more constant in the face of changing network conditions. The effect is to make distant connections behave as if they were local. User-perceived responsiveness remains constant regardless of link utilization. Unlike normal TCP, with which a WAN operating at 90% utilization is useless for interactive tasks, an accelerated link has the same responsiveness at 90% link utilization as at 10%.

With short-haul connections (ones that fall below the diagonal line in the figure above), little or no acceleration takes place under good network conditions, but if the network becomes degraded, performance drops off much more slowly than with ordinary TCP.

Non-TCP traffic, such as UDP, is not accelerated. However, it is still managed by the traffic shaper.


One example of CloudBridge's advanced TCP optimizations is a retransmission optimization called transactional mode. A peculiarity of TCP is that, if the last packet in a transaction is dropped, its loss not noticed by the sender until a receiver timeout (RTO) period has elapsed. This delay, which is always at least one second long, and often longer, is the cause of the multiple-second delays seen on lossy links-delays that make interactive sessions unpleasant or impossible.

Transactional mode solves this problem by automatically retransmitting the final packet of a transaction after a brief delay. Therefore, an RTO does not happen unless both copies are dropped, which is unlikely.

A bulk transfer is basically a single enormous transaction, so the extra bandwidth used by transactional mode for a bulk transfer can be as little as one packet per file. However, interactive traffic, such as key presses or mouse movements, has small transactions. A transaction might consist of a single undersized packet. Sending such packets twice has a modest bandwidth requirement. In effect, transactional mode provides forward error correction (FEC) on interactive traffic and gives end-of-transaction RTO protection to other traffic.