Xpress Overview

Packeteer's Xpress feature allows you to use compression to increase the virtual size of WAN bandwidth, use acceleration to fully utilize bandwidth on high latency environments, and use compression and/or acceleration to improve application performance on your network. By integrating these technologies with traffic management, PacketWise ensures that the increased virtual WAN pipe is not consumed by aggressive, non-mission critical applications that burst to consume any bandwidth given to them. In addition, the effective throughput of the mission critical traffic can also increase, providing a double benefit. Traffic management protects mission critical traffic, contains recreational and unsanctioned traffic, and smoothes peaks in bursty traffic, while Xpress provides greater throughput and network capacity.

Xpress works by identifying other PacketShaper units on the network, dynamically setting up a communication link, called a tunnel, between the units, and sending data through the tunnels.

What are Tunnels Used for?

Xpress uses tunnels to transport compressed data, packed data, and/or accelerated data. Each of these features is described in the following sections.

Note: Compression and packing are features included with the compression key. Acceleration requires the acceleration key.

Compression

Xpress compression shrinks the size of transferred traffic, effectively increasing the amount of bandwidth available on a link. It uses a variety of methods, called compression algoriths, to compress data, for example ICNA, CNA, PRED1, PRED2, and RETD. You can enable/disable compression globally or for a specific tunnel.

Xpress does not attempt to compress all traffic. Because PacketShaper is application intelligent, it is able to identify each traffic flow and compress only the flows that are likely to achieve useful gains. Previously compressed traffic (such as streaming media) and encrypted data (such as Telnet-Secure, FTP-Cmd-Secure, IMAP-Secure) are examples of non-compressible traffic. The ability to apply appropriate compression algorithms to different applications is built into the Xpress compression engine. Xpress automatically assigns the appropriate algorithm to each application, in order to achieve the best compression ratio, with minimal latency. For example, VoIP services are automatically assigned an algorithm that just compresses the UDP headers (since the body is already compressed).

There are several things to keep in mind regarding compression. First, a packet’s uncompressed data size is used for all calculations relating to flows and their policies (such as the guaranteed rate). Second, PacketShaper uses the compressed data size for calculating how much data can fit in a partition. For example, if you create a 150K partition, Xpress will allow 150K of compressed data in the partition (which could be 300K of uncompressed data, assuming a 2:1 compression ratio). Third, the standard measurement variables measure the actual data (compressed and uncompressed) that passes through the link. Measurement variables specific to compression are available, allowing you to analyze the effectiveness of compression on your link. For a list of these variables, see Compression Measurement Variables.

Packet Packing

When Xpress packing is enabled, multiple packets are combined into a single "super packet" before being sent through the Xpress tunnel. Since fewer packets are sent, packing saves on overhead introduced by packet headers. You can enable/disable packet packing globally, for a specific tunnel, or on a per-class or per-service basis. Packing is a feature that is included with the compression key.

The maximum size of the super packet is determined by the Maximum Transfer Unit, or MTU. MTU is the largest datagram than can be transmitted by an IP interface, without it needing to be broken down into smaller units. Because the packet size is maximized to the MTU, packing improves link utilization. The MTU can be set globally or for an individual tunnel.

Since different types of traffic can tolerate different amounts of latency, each service is assigned an appropriate packing hold time — the length of time the super packet is held to wait for additional packets to be packed into it. For example, services that are sensitive to delay are assigned a 1 ms packing hold time; Telnet and Skype are two examples of services that would fall into this category. The default packing settings are appropriate in most situations, but CLI commands are available to fine-tune these settings if you find the need.

Due to the inherent delay in the process of combining packets, packing will increase network latency. On very busy links, packing doesn't cause much latency because the packets are bundled and sent off quickly. On less active links, Xpress may have to wait to get enough packets in a bundle, possibly creating application performance problems. If you are experiencing latency, try lowering the packing hold time or disabling packing altogether.

Packing is most efficient and effective when dealing with small packets or packets that can be reduced in size with compression. 

Acceleration

The acceleration module significantly improves the performance of TCP/IP over satellite links or long-delay terrestrial networks. It accelerates both transactions and file transfers to enhance network performance. Xpress acceleration allows you to maximize bandwidth utilization, speed up application response times, accelerate the transfer of large files, and minimize the impact of other problems that are common with TCP-based applications on high-latency links. A high-latency environment is generally any link with ping time of 150 ms or more. Virtually all overseas connections and the majority of East Coast - West Coast US links are high latency.

The benefits of acceleration are not restricted to networks with high latency — other factors come into play as well. High-speed links with small window sizes and moderate latency can also benefit from Xpress acceleration. For example, a data center with a 45 Mbps link, using Windows 2000 with a 16K window size, has a 30ms round-trip time during data backups. Because of the small window size, the link is underutilized and is less than 10 percent full. With Xpress acceleration, the data center would be able to fully utilize the bandwidth in the 45 Mbps link and perform the backup 10-100 times more quickly.

You can enable/disable acceleration globally or for a specific tunnel.

Transport Acceleration: XTP or SCPS

PacketWise supports two types of transport acceleration: XTP and SCPS.

With XTP, Xpress intercepts the TCP connection from the client and converts the data to XTP (Xpress Transport Protocol) for transmission through the Xpress tunnel. The PacketShaper unit on the other side of the tunnel translates the XTP data back to TCP.

XTP is a reliable protocol optimized for high-latency links. The XTP implementation in Xpress includes a rate-based congestion control which allows a connection to quickly attain full-speed operation when significant bandwidth is available. Over long distance networks, where acknowledgements are slow to return, the TCP window size often sets a hard limit on the maximum throughput rate. Large links become less and less utilized as delay increases because valuable time is spent simply waiting for acknowledgements. To look at an example, on a 45 Mbps link, approximately 88 percent of the bandwidth is wasted due to TCP and window size limitations. Using Xpress acceleration allows you to more fully utilize the bandwidth in the WAN link.

An alternative transport acceleration protocol is SCPS (Space Communications Protocol Standards). When SCPS is enabled, it becomes the transport protocol for the transmission of data over the satellite portion of the link. Although XTP provides higher performance than SCPS under most conditions, there are two situations where SCPS mode is recommended:

• Links where the use of SCPS is required for interoperability with other SCPS-based acceleration products.
• When an organization has standardized on SCPS as the required transport protocol.

HTTP Acceleration

The acceleration module is able to significantly improve performance of web-based applications on high-latency links. When acceleration is enabled, web pages display significantly faster. Two features allow you to accelerate HTTP traffic: FastStart and Prefetch. These features can be enabled together or separately.

The FastStart feature accelerates web downloads by reducing the time needed to establish each new HTTP connection. Using FastStart, Xpress acknowledges TCP connections immediately without waiting for a connection to be established to the web server. This immediate acknowledgement allows the browser to send its HTTP GET request right away. Xpress then combines the HTTP GET request with the XTP connection request. This process delivers the HTTP request to the web server one round-trip faster. For web pages that consist of large numbers of objects, FastStart greatly improves the responsiveness of the web page display.

The Prefetch feature reduces the time required to download and display web pages. The server-side Xpress/SkyX unit intercepts the HTML pages returned by the web server and begins retrieving the various embedded graphics and objects on that page. The server-side Xpress then pushes the objects to the remote side of the link where they are served by the client-side Xpress/SkyX unit when requested by the browser, thereby avoiding the network delay.

FastStart and Prefetch work on HTTP traffic running on ports 80 or 8080.

Creating Xpress Tunnels

Xpress tunnels are created automatically when all of the following conditions are met:

• Tunnel host and partner discovery is enabled.
• A flow is destined for a host on the other side of a PacketShaper or a flow is received from a host on the other side of PacketShaper.
• The two PacketShapers are configured outside port to outside port. (illustration)
• An Xpress-IP address is configured for each PacketShaper device (built-in NIC or LEM) you want to use for Xpress compression, packing, or accceleration.
• No NAT devices are between tunnel partners.

Tunnels that are auto-discovered in this manner are called dynamic tunnels.

Optionally, you can manually configure an Xpress tunnel by specifying the device to configure on the local unit (such as the main interface or upper LEM) and the IP address of the partner PacketShaper. Tunnels that you manually create are called static tunnels. Note that this tunnel will appear as a dynamic tunnel on the partner.

Dynamic Xpress tunnels can be converted to static tunnels so that the settings can be fine tuned. Because certain settings (such as manually adding remote hosts) can be configured for static tunnels only, you'll need to convert the tunnel to static if you want to adjust these settings.

Each Packeteer model has a limit to the number of Xpress tunnels that can be automatically or manually created. See Configuration Limits for specifications.

Creating SkyX Tunnels

SkyX Accelerator is Packeteer's dedicated acceleration hardware device that provides functionality similar to Xpress acceleration: it accelerates TCP over high-latency links. Xpress has the ability to form a tunnel between a SkyX Accelerator and a PacketShaper unit, allowing you to accelerate traffic between hosts on one side of a PacketShaper and hosts on the other side of a SkyX Accelerator. This type of tunnel, called a SkyX tunnel, requires that you manually create a static tunnel that is SkyX compatible.

A SkyX tunnel has the following characteristics:

• Accelerates traffic with XTP unless SCPS is enabled
• Uses global settings for Prefetch and FastStart
• Does not compress or pack traffic
• Options for firewall support, DiffServ support, and auto-discovery of hosts and partners are not applicable.

Xpress Modes

To help in the transition to the new capabilities in Xpress, three modes are offered: enhanced, legacy, and migration.

• Legacy mode uses the PacketWise v6.x/7.x tunnel infrastructure. In legacy mode, the commands and capabilities are limited to those that were available in PacketWise 7.x. A tunnel's sole capability is to transport compressed data. Packing capability is available via a system variable.
• Enhanced mode uses the new 8.x tunnel infrastructure. In enhanced mode, a tunnel serves multiple purposes and can include one or more of the following features: compression, acceleration, and packing. Although the basic functionality of compression is the same in legacy and enhanced modes, enhanced compression is more efficient, has better firewall and MPLS support, and is more tolerant to latency and loss. Instead of the IPCOMP protocol used in legacy compression, enhanced mode transports compressed data with TCP in stateful mode and raw IP (protocol 99) in stateless mode.
• Migration mode supports both types of tunnels: legacy and enhanced. Use this mode when migrating from earlier versions of PacketWise. By default, 50 percent of compression memory is allocated to legacy compression tunnels and 50 percent is assigned to enhanced Xpress tunnels. This ratio can be modified.

The default mode for new installations is enhanced mode. The default mode for units that have upgraded to 8.x is migration mode, in most cases. The exception is when watch mode or direct standby is enabled before the upgrade. If either feature is enabled in 7.x, the unit will be in legacy mode after the upgrade. (This is because watch mode and direct standby only operate in legacy mode.) For more information, see Select the Xpress Tunnel Mode.

Getting Started

For step-by-step instructions on getting started with Xpress, see Configure Xpress. Or, if you are upgrading from PacketWise 7.x to 8.x, follow the procedure detailed in Migrate to Xpress.

Once Xpress is properly configured, you can use the following monitoring and reporting tools:

• To see a list of Xpress tunnels that have formed with your PacketShaper, use the xpress tab. For more information, see Monitor Xpress Tunnels.
  
  
• To see how compression is working on your link, you can look at compression reports. The report tab offers a Compression Summary, the Statistics:Reports page has compression reports for links, partitions, and classes, and the top ten tab offers views for Top Ten - Compression Bytes Saved and Top Ten - Compression % Bytes Saved.
  
  
• For acceleration, you can view the Acceleration Summary on the report tab.

Requirements and Limitations

• Xpress is available on the following PacketShaper models: 1200, 1400, 1550, 2500, 3500, 6500, 7500, 8500, 9500, and 10000. It is not available on Packeteer 1500 or 4500 models.
  
  
• Xpress is not available on PacketShaper ISP models.
  
  
• If there is a firewall between partner PacketShapers, firewall support must be enabled. See Configure Global Xpress Settings and Modify Settings of Static Tunnels.
  
  
• To use compression on a DiffServ network, you will need to enable DiffServ mode. See Configure Global Xpress Settings and Modify Settings of Static Tunnels.
  
  
• On a point-point link, PacketShapers can shape and compress traffic when connected back-to-back via routers, bridges, or VPN connections.
  
  
• To use Xpress on existing PacketShaper units, you need to purchase an Xpress compression and/or acceleration software key from Packeteer, and install it onto each unit.
  
  
• You must configure an Xpress-IP address for each PacketShaper device (built-in or LEM) you want to use for Xpress compression, packing, or acceleration. See Define Xpress-IP Settings.
  
  
• If Xpress is deployed in a Virtual Private Network (VPN), the (private) address space on both sides of the VPN tunnel between the PacketShaper units needs to be separate and unique in order to allow the two units to set up an Xpress tunnel.
  
  
• Multicast traffic will get compressed if the Class D (226.x.x.x) addresses are added to remote and/or local host lists (see tunnel local add and tunnel remote add). However, unlike unicast compression hosts, multicast hosts will not be discovered automatically. In order for the traffic to get disseminated to multiple recipients, the decompressed multicast traffic must be forwarded to a router; if not, only one host will receive the flow. Note that multicast traffic cannot be accelerated.
  
  
• Direct standby and watch mode are not available with enhanced Xpress tunnels. These features can be enabled only when PacketShaper is set to legacy tunnel mode.
  

Acceleration

• The site router should be set to none if you are using acceleration.
  
  
• For best performance, Packeteer recommends that shaping be enabled when using acceleration.
  
  
• When acceleration is enabled, a flow gets divided into three separate segments (TCP, XTP, TCP), and a single PacketShaper cannot know the state of segments to which it isn’t directly connected. This means that flows in an acceleration tunnel cannot take advantage of inbound TCP Rate Control, which requires an end-to-end view of the complete connection. Instead, PacketShaper uses UDP Rate Control techniques to control latency and minimize packet loss in accelerated flows.
  
  
• Another implication of TCP being converted to XTP is that the response-time measurement (RTM) variables aren’t able to measure a transaction through its complete round trip, and do not account for the portion that is not TCP. Because of this, RTM data is not meaningful and should not be used or relied upon if acceleration is enabled.
  
  
• In nested PacketShaper configurations (PS1-PS2-PS3-PS4), if the middle units (PS2 and PS3) have acceleration enabled and discovery off, accelerated XTP traffic that is sent between the outer units (PS1 and PS4) will get blocked. This configuration is not supported in PacketWise 8.x.