Product Documentation

About CloudBridge

Oct 27, 2016

Citrix CloudBridge appliances optimize your WAN links, giving your users maximum responsiveness and throughput at any distance. A CloudBridge appliance is easy to deploy, because it works transparently. A twenty minute installation accelerates your WAN traffic with no other configuration required. You do not have to change your applications, servers, clients, or network infrastructure. You can, however change them after CloudBridge installation without affecting traffic acceleration. A CloudBridge appliance needs reconfiguration only when your WAN links change.

CloudBridge appliances support a full range of optimizations, including:

  • Multi-session compression with compression ratios of up to 10,000:1.
  • Protocol acceleration for Windows network file systems (CIFS), XenApp (ICA and CGP, including the new multi-session ICA standard), Microsoft Outlook (MAPI), and SSL.
  • Traffic shaping to ensure that high-priority and interactive traffic takes precedence over low-priority or bulk traffic.
  • Advanced TCP protocol acceleration, which reduces delays on congested or high-latency links.
  • Video caching.

 

How CloudBridge Works

CloudBridge products work in pairs, one at each end of a link, to accelerate traffic over the link. The transformations done by the sender are reversed by the receiver. 

However, one appliance (or virtual appliance) can handle many links, so you do not have to dedicate a pair to each connection. 

An enterprise typically has one CloudBridge appliance per site (larger appliances at larger sites, smaller ones at smaller sites), though a company with numerous branch offices might have multiple appliances at its central data center.

A link from a site with a CloudBridge appliance to a site that does not have a CloudBridge appliance functions normally, but its traffic is not accelerated.

CloudBridge features include robust compression for brisk performance over relatively slow links, and lossless flow control to deal with congestion. TCP optimizations overcome the main limitations of problematic links, and application optimization does away with the limitations of applications designed for high-speed, local networks. An autodetection feature makes deployment quick and easy.

 

CloudBridge Features and Benefits

Any time workers spend waiting for their computers to respond is lost time, resulting in lost productivity. When users work remotely or use off-site resources, their productivity depends on the responsiveness of their network connections. Safeguarding the responsiveness of their connections requires advanced network acceleration.

The Citrix CloudBridge product line protects your productivity by providing reliable WAN and Internet link performance through a set of multiple, interlocking optimizations, each reinforcing the others. To provide maximum productivity across your entire enterprise, there are CloudBridge products for every need, from the largest data center though the smallest branch office and even the individual laptop.

CloudBridge provides robust usability even with undersized or degraded links.

Features at a Glance

 

Feature Benefits
Compression
  • Increases speed by reducing transfer size
  • Delivers compression ratios of up to 10,000:1
  • Works at LAN speeds for maximum performance
  • Reduces bandwidth requirements
  • Application independent
  • Increases robustness
  • Zero-config
TCP Protocol Acceleration
  • Optimizes all TCP connections
  • Increases link utilization and effective bandwidth
  • Eliminates congestion
  • Minimizes queuing and retransmission delays
  • Increases robustness
  • Zero-config
Traffic Management
  • Traffic shaper optimizes link usage
  • Prevents “rogue” applications from interfering with other traffic
  • Traffic classifier allows advanced control and reporting
Application Acceleration
  • HTTP
  • Network Filesystems (CIFS/SMB)
  • Video Caching (Video over HTTP)
  • Email Acceleration (MAPI)
  • SSL Acceleration
Citrix XenApp/XenDesktop (HDX) Acceleration
  • Uses complete protocol knowledge for ideal performance
  • Optimized compression for each service (screen, video, file transfer, etc.)
  • Optimized traffic shaping for each service
  • Multistream support
  • Maintains end-to-end encryption
  • Zero-config
Integration
  • CloudBridge Plug-in Windows client
  • CloudBridge Connector IPSec VPN
  • CloudBridge with Windows Server integrated appliances
  • CloudBridge VPX virtual machine for XenServer, VMware vSphere, Hyper-V, Amazon AWS
Monitoring and Management
  • Integrated into HDX Insight Center
  • Integrated into Citrix Command Center
  • AppFlow, SNMP, syslog monitoring

 

Features and Benefits

The following are some of the key benefits of our CloudBridge product line.

 

Compression Overcomes Low Link Speeds. The most obvious problem with wide-area network (WAN) links and Internet links is their low bandwidth compared to local-area networks (LANs). A 1 Mbps WAN has only 1% of the throughput of a 100 Mbps LAN. How do you overcome low link bandwidth? With compression. A compression ratio of 100:1 enables a 1 Mbps link to transfer data as quickly as a 100 Mbps. This speedup factor is achieved whenever the following criteria are met:

  • The compression algorithm must be able to deliver high compression ratios.
  • The compression algorithm must be very fast (much faster than the link bandwidth, and ideally as fast as the LAN).
  • The LAN segments of the link must have flow control that is independent of the WAN segment, because the different segments handle data at different rates.
  • Multiple compression engines must be used to handle the different needs of different kinds of traffic. Interactive traffic requires relatively little bandwidth but is very sensitive to delay, while bulk-transfers are very sensitive to bandwidth but are insensitive to delay.

 

TCP Protocol Acceleration Overcomes Congestion. Any attempt to send traffic faster than the link speed results in congestion, which results in many problems caused by high packet losses and high queuing latency.

Lossless flow control. The TCP/IP protocol has no flow control to slow senders down directly, and the absence of this necessary control mechanism makes packet losses and excessive queuing delays normal, even on mission-critical links. (If anything, this problem is getting worse over time, as papers on the phenomenon of bufferbloat attest.)

 

A CloudBridge appliance solves this problem by providing the flow control that was omitted from the TCP/IP protocol. Unlike ordinary quality of service (QoS) solutions, which simply reallocate packet loss, CloudBridge provides lossless flow control that controls the rate at which the endpoint senders transmit data, instead of allowing senders to transmit data at any speed they like, and dropping packets when they send too much. Each sender transmits only as much data as CloudBridge allows it to send, without ever dropping a packet, and this data is placed on the link at exactly the right rate to keep the link full without overflowing. By eliminating excess data, CloudBridge is not forced to discard it. Without CloudBridge, the dropped packets have to be sent again, causing unnecessary delays. Lossless flow control also eliminates delays caused by excessive buffering. Lossless flow control is the key to maximum responsiveness on a busy link, enabling a link that was once congested to the point of unusability at 40% utilization to remain productive and responsive at 95% utilization.

Eliminating distance-based unfairness.  Links with high latency or packet losses are difficult to use at full bandwidth, especially with ordinary TCP variants such as TCP Reno. The consequences are excessive delays and difficulty in getting the bandwidth that you are paying for. The longer the link distance, the worse the problem becomes.

 

CloudBridge TCP protocol acceleration minimizes these effects, allowing intercontinental and even satellite links to run at full speed.

Traffic Shaping Manages Bandwidth Automatically. On the output side, a fair-queuing-like algorithm ensures that each connection is independently queued and given its fair share of the link bandwidth. Traffic-shaping policies allow different services to be given higher or lower precedence.

 

Application Optimizations Overcome Design Limitations

Applications and protocols designed for use on local-area networks are notorious for poor performance over wide-area networks, because the designers did not consider the effects of long speed-of-light delays on their protocols. For example, a simple Windows file system (CIFS) operation can take up to 50 round trips as messages pass back and forth across the network. In a wide-area network with a 100 ms round-trip time, 50 round trips cause a delay of five seconds.

Although speed-of-light delays are a fundamental limitation, application optimizations can perform the same operations in a smaller number of round-trips, usually through speculative operations. Where the original application would issue one command at a time and wait for it to complete before issuing the next one, it is often perfectly safe to issue a series of commands without waiting. In addition, data transfers can be accelerated through a combination of pre-fetching, read-ahead, and write-behind operations. By packing as many operations as possible into a single round trip, performance can be increased tenfold or more.

CloudBridge optimizations are especially effective on CIFS/SMB (the Windows file system), MAPI (the Outlook/Exchange protocol), and HTTP.

 

Multiple Optimizations Enhance XenApp/XenDesktop (Citrix HDX) Performance. Because CloudBridge appliances are Citrix products, they are especially effective at accelerating Citrix protocols, such as XenApp and XenDesktop. Every aspect of CloudBridge acceleration comes into play with these protocols to make the remote user experience as productive as possible.

 

CloudBridge appliances negotiate session options with XenApp and XenDesktop servers. This allows the CloudBridge appliance to apply the following enhancements:

  • It replaces the server's native compression with higher-performance CloudBridge compression.
  • It bases the connection's traffic-shaping priority on the priority bits embedded in every XenApp and XenDesktop connection. This allows the priority of the connection to vary according to the type of traffic. For example, interactive tasks are high-priority tasks and print jobs are low-priority tasks.
  • It gathers and reports statistics based on the XenApp or XenDesktop applications being used.
  • It maintains the end-to-end encryption of the original connection.

 

Autodetection for Minimal Configuration. Because the CloudBridge solution is double-ended, requiring that a CloudBridge product be present at both ends of the link, deployment would seem to impose a burden on remote offices, especially ones without dedicated IT staff. However, CloudBridge is designed to be very easy to install and maintain. A typical installation takes about twenty minutes. The only parameters needed are the usual network parameters (such as IP address and subnet mask), the address of a Citrix license server, and the send and receive speed of the link.

Requiring only a minimal level of configuration is possible because of autodetection, through which a CloudBridge determines which connections can be accelerated (and which cannot), without any manual configuration. A CloudBridge at the other end of the link is automatically detected, and the connection is then accelerated. You can add CloudBridge appliances to your network in an ad hoc fashion. You do not even have to inform the existing appliances of the arrival of a new one. They discover it for themselves.

A CloudBridge uses TCP header options to report its presence and to negotiate acceleration parameters with the remote CloudBridge. Because TCP header options are part of the TCP standard, this method works very well, except in cases where firewalls are programmed to reject all but the most common options. Such firewalls exist, but they can be configured to allow the options used by CloudBridge to pass through.

CloudBridge operations are transparent to both the sender and receiver. The other devices in your network are not aware that CloudBridge exists. They continue working just as they did before CloudBridge installation. This transparency also eliminates any need to install special software on your servers or clients in order to benefit from CloudBridge acceleration. Everything works transparently.

 

Product line capabilities

Every product in the CloudBridge product line provides basic CloudBridge acceleration features. Most models have additional features as well, such as:

  • Video caching
  • Multiple accelerated bridges with Ethernet bypass feature
  • Monitoring and management through the GUI, CLI, SNMP, AppFlow, and Citrix Command Center

Different CloudBridge products have different capabilities. Products that support higher WAN bandwidths also support more users and typically have more resources: more power CPU, more memory, larger disk, and more accelerated bridges.

The capabilities of products that run on your own hardware, such as the CloudBridge Plug-in and CloudBridge VPX, depend on the speed of the hardware and the amount of system resources that you dedicate to acceleration.

 

For up-to-date specifications, see the CloudBridge Product Data Sheet.

 

CloudBridge Architecture

Citrix CloudBridge appliances accelerate the traffic over you WAN links. To accelerate a WAN, you need at least two CloudBridge appliances, one for each site you wish to accelerate.

The sender-side CloudBridge appliance applies a series of optimizations and transformations to your traffic, such as compression and encryption. Many operations require that the receiver-side CloudBridge perform an inverse operation, such as decompression or decryption, to restore the traffic to its original state.

Thus, most optimizations require that the traffic pass through two CloudBridge appliances. Some optimizations are single-ended, and are performed by the local appliance acting alone. These optimizations include traffic shaping and video caching.

CloudBridge appliances are largely transparent to the network. The appliance itself appears to be a bridge, not a router, gateway, or proxy. This invisibility allows the appliance to be installed without configuring any other hardware. The appliance optimizations are also transparent, detected only by the partner appliance at the other end of the link.

CloudBridge appliances can be added to the network at will, because their auto-detection and auto-negotiation features ensure that a new appliance on the network is immediately detected by other appliances, and acceleration begins at once.

Although the diagram above shows a network with just two appliances, a single CloudBridge appliance can communicate with any number of partner sites. Point-to-point, hub-and-spoke, and mesh networks are all supported.

In addition to stand-alone appliances, CloudBridge acceleration products include virtual machines (the CloudBridge VPX series) and an installable acceleration service for Windows systems (the CloudBridge Plug-in).

What Acceleration Means

In CloudBridge terminology, “acceleration” is the reduction of transaction time, which reduces the time users spend waiting. Because the time that users spend waiting represents a direct productivity loss, acceleration’s main benefit is increased productivity.

In network traffic, a transaction ranges from very small—a single byte of data in a telnet or SSH terminal session—to very large, as with FTP transfers, which often exceed a gigabyte in size. A practical accelerator has to accelerate the entire range of transaction sizes, from interactive traffic to bulk traffic, giving the best performance and user experience across the board. CloudBridge technology achieves this in a variety of ways.

How Acceleration Works: The Pipeline

To see how the CloudBridge appliance works, take a close look at the diagram of the traffic-flow pipeline. As you can see, there are two pipelines:

  1. The sending pipeline, which accelerates data entering the WAN from the local LAN.
  2. The receiving pipeline, which accelerates data exiting the WAN and entering the local LAN.

 

localized image

Sending Pipeline

To understand the appliance, consider the sending pipeline one unit at a time.

  1. Input buffer. Packets from the LAN are received by the appliance. Because non-TCP/IP traffic is optimized only by the traffic shaper, non-TCP packets are diverted directly to the traffic shaper. The TCP/IP traffic (called TCP traffic from now on) traverses the rest of the pipeline.
  2. Video Cache. If the TCP traffic matches the settings for the video cache, the request is handed off to the video cache unit.
  3. LAN-side auto-detection. Other than traffic shaping, sender-side optimizations require that there be a remote appliance as well as the local appliance. Any connections that don’t pass through a remote appliance are diverted to the traffic shaper. This action is performed by the LAN-side auto-detection logic. The actual test for a remote appliance is done by the WAN-side auto-detection unit.
  4. LAN-side flow control. CloudBridge acts as a transparent TCP proxy, receiving and acknowledging packets from the endpoint sender on behalf of the endpoint receiver. This allows the appliance to accept large amounts of data from the local sender very quickly, at full LAN speeds, regardless of how slowly traffic is moving over the WAN. (Normal TCP uses end-to-end speed control, which is not agile enough to allow maximum performance.) In addition, CloudBridge flow control is lossless, meaning that the local sender never sees a dropped packet, increasing reliability and efficiency.
  5. Application engines. CloudBridge performs specific optimizations for several protocols, including:
    • XenApp and XenDesktop, using the ICA and CGP protocols.
    • Windows Filesystem (CIFS, including the SMB1 and SMB2 versions)
    • Outlook/Exchange (MAPI)

      These optimizations reduce transaction time. This is done through rewriting, combining, and reordering commands, using read-ahead and write-behind, using a knowledge of the protocol for more advanced traffic shaping, and compression hinting.

  6. Compression engine. Compression makes the transactions smaller, reducing the time it takes to transfer the data over the link. The CloudBridge compressor uses multiple compression algorithms, some very efficient for small transactions, some optimized for bulk transactions, and some for midsize transactions. Compression ratios of 10,000:1 are readily achieved by the CloudBridge compressor. The compressor is very fast, allowing high compression ratios to be maintained at full WAN speeds. With CloudBridge processing, a file that compresses at a 100:1 ratio can easily be sent over a 1 Mbps link with an overall throughput of 100 Mbps.
  7. Security engine. Some CloudBridge features require that the two appliances enter a secure peer relationship with each other, and with the origin server. The security engine authenticates this peer relationship and encrypts the accelerated data connections between them. A secure peer relationship allows the use of SSL compression and the acceleration of encrypted XenApp/XenDesktop (ICA/CGP), Windows Filesystem (CIFS), and Outlook/Exchange (MAPI) traffic.
  8. WAN-side flow control and auto-detection. The WAN link is where traffic slowdowns occur, and if the link is congested, packets are lost and must be retransmitted. Retransmitting packets always causes a significant delay, sometimes lasting more one second. The WAN-side flow-control unit uses advanced retransmission elements and an advanced TCP/IP protocol for maximum performance in both “clean” and “troubled” links. The auto-detection unit identifies the presence of a partner CloudBridge unit on a connection-by-connection basis, which prevents optimizations from being used where they are not wanted, and allows new appliances to be detected by the existing ones as soon as they are added to the network. Auto-detection uses options in the TCP header field. This is normally transparent but might be blocked by some firewalls, which need to be reconfigured.
  9. Application classifier. This unit examines all the traffic flowing through CloudBridge and identifies which application or protocol it belongs to. This information is used in reporting and by the traffic shaper.
  10. Traffic shaper. To avoid congestion, excessive queuing, and other sources of avoidable delays, the traffic shaper injects traffic onto the WAN at slightly less than the WAN’s data rate, to ensure that the WAN is never overrun. A weighted fair queuing algorithm is used to ensure that all traffic gets its fair share of the link bandwidth. Traffic-shaping policies allow different traffic types to receive different weights, so that some traffic gets more bandwidth than others.

Receiving Pipeline

The pipeline in the receiving direction is similar to the sending direction, except that instead of encrypting, it decrypts, and instead of compressing, we have decompresses. Also, note that there is a traffic shaper in the receiving direction as well, applying traffic-shaping policies to incoming WAN traffic, so that both directions are regulated.

Auto-Detection and Packet-Level Transformation

The auto-detection algorithm inserts TCP header options to announce the presence of a CloudBridge appliance and to facilitate negotiation. These options are in the range of 24-31. The following packet-level transformations are used:

  • On the initial packet of the connection (the SYN packet), the sending appliance attaches header options identifying itself as a CloudBridge appliance, and also declaring other capabilities, such as compression. This is called a “tagged SYN packet.”
  • Upon receiving a tagged SYN packet, the receiving appliance attaches header options to the SYN-ACK packet, identifying itself in turn and announcing its capabilities.
  • Once the sending appliance receives the tagged SYN-ACK packet, the connection can be accelerated according to whatever capabilities are shared by both appliances. For example, the connection is compressed if both appliances declared support for compression.
  • The TCP initial sequence numbers (ISNs) in both directions are altered by adding 2,000,000,000 to the original values. This is a precaution that prevents the connection from continuing if one appliance fails or has a routing change that prevents it from seeing all the traffic in the connection. Once a connection is accelerated, it must remain accelerated throughout its lifetime.
  • The MSS value is reduced, typically to 1380 bytes, to ensure that each packet has room for the inserted CloudBridge TCP header options.
  • The IP addresses and port numbers of the connection remain unchanged.

Pre-Acknowledgement

The SYN and SYN-ACK packets flow from end to end:

  • The SYN packet flows from the endpoint client, through the client-side appliance, over the WAN, through the server-side appliance, and finally to the server.
  • The SYN-ACK packet flows from the server, though the server-side appliance, over the WAN, through the client-side appliance, and finally to the client.

The same is true for the final packets of the connection, the FIN, FIN-ACK, and RST packets.

Other packets, however, are pre-acknowledged. For example, when the server-side appliance receives a packet from the server, it acknowledges it over the LAN right away, and buffers it for eventual transmission over the WAN. This allows the server-side appliance’s buffers to be filled very quickly, so it always has plenty of data to use for compression and other optimizations. (This is very different from normal TCP operation, where all acknowledgements come from the opposite side of the WAN, making acknowledgement very slow, and forcing every segment of the connection to move no faster than the slowest segment, greatly reducing the effectiveness of acceleration.)

Moving Traffic Into and Out of the Appliance

CloudBridge appliances have a number of “forwarding modes.” A forwarding mode is a method of getting traffic into and out of the appliance. The most common is inline mode, where the CloudBridge appears to be a bridge device. Packets entering on one bridge port appear to exit the other one. Of course, CloudBridge transforms data in a variety of ways, so in many cases the packet exiting the second port is not identical to the one that entered the first port, but that is how it appears to the rest of the network.

Where inline mode is not practical, several other methods are available, most notably WCCP mode. These are “one-arm” modes, using a single interface cable.