As any user of satellite networks quickly realizes, space links just don’t work that well when TCP is used for applications such as file transfers or Internet surfing. In this article, we will recap traditional TCP acceleration functions developed during the late 1990’s, then move on to describe new features and functions that deliver even more bandwidth gain — combinations that are only possible by virtue of leveraging today’s computing power with the major advancements in memory management.

The Beginning — TCP Acceleration
The original TCP algorithms can generically be described as connection oriented, with guaranteed data delivery that operates in an uncoordinated yet cooperative way to share the available bandwidth. As we all have witnessed, this model has worked across various link types for many years, far beyond the Ethernet and Token Ring LAN networks that existed in the early days of data networking.

Today, TCP / IP is used worldwide to connect clients to Internet servers across networks that include an incredible mix of wireless, fiber optics, and wire-line services. During the middle 1990’s, early users of satellite connections recognized that TCP was less than speedy in establishing an initial connection and the transfer rate was painfully slow, rarely, if ever, approaching the maximum link capacity. When packet loss occurred on those links, traditional TCP packet recovery algorithms actually caused an increase in packet loss. Subsequently, even more retransmissions were required while the protocol tried to catch up to the lost data. This was a well-understood and vicious cycle. A casual user would not notice this occurrence, only observing that transmissions started out slowly and seemed to get worse as time went on!

Wireless, and satellite links in particular, share a few common characteristics that are the underlying cause of such poor performance.

• Dynamic Bandwidth — wireless links rapidly change capacity
• High packet loss — bit error rates are many orders greater
• Asymmetry — links and overlay networks where senders and receivers are using different link types and power levels

To address these issues, a set of TCP modifications for use across space-based communication links was created. These modifications speed up initial connections and the transfer of data to achieve the true link capacity, while also increasing the efficiency of recovering lost packets, a frequent occurrence on satellite links. Implementation of these new algorithms resulted in the emergence of hardware appliances termed a Performance Enhancing Proxy, commonly referred to as a PEP. This is a device that intercepts TCP connection requests before they are sent over the satellite link and proxies those requests on behalf of the user. The proxy opens a new session using modified TCP algorithms for the initial connection and specialized recovery algorithms during the transfer of data to maximize the link utilization — the end-user is unaware that this has occurred.

PEP devices are installed in-line between the LAN segment and the satellite terminals or wireless modems on the hub-site and each remote site and operate over any IP network topology. During this phase of TCP acceleration, there was a general assumption that one device resided on each end of a connection and there was no ability to aggregate multiple, remote sites on a single hub-side appliance.

The bandwidth gain resulting from protocol acceleration can be generally characterized as filling a wireless link to the full capacity. Using proprietary Transport Controls, this can be done on even short duration flows such as the connections and quick data transfers web servers use to send custom advertisements to all of us.

Standards Based Protocol Acceleration
As PEP technology became accepted as a required component in virtually all space communications systems, a set of default TCP algorithms was defined in an industry standard called the Space Communication Protocol Standard – Transport Protocol (SCPS-TP). SCPS (pronounced skips) defines a minimum level of interoperable TCP operations between SCPS compliant proxies from different vendors, in case two users encounter each other over any kind of wireless link. The Defense Information Systems Agency (DISA) for the US Department of Defense now mandates compliance with this standard for any equipment used to optimize satellite connections.

Data Compression, The Wireless Optimizer
By design, the SCPS-TP standard left plenty of room for vendors to innovate, anticipating vendor enhancements to TCP when used across a wireless link. By identifying other functions, a vendor can implement multiple data compression techniques that operate on the accelerated data prior to transmission, while remaining SCPS compliant for protocol acceleration. Data compression is the point at which PEP interoperability between vendors may be lost, as the data compression and decompression technique must be common to both ends of the connection, much like encryption.

Standards based PEP vendors remain capable of negotiating TCP protocol acceleration for use on the connection, but other options to increase bandwidth gain and link efficiency may be ignored unless both ends are similarly equipped. Protocol acceleration and data compression operate in the upstream and downstream direction for all TCP applications. This is called Streaming Data Compression as it operates on multiple packets in a stream, potentially reducing the overall number of packets needed to send data, rather than simply compressing the payload of each packet. Because each optimizer appliance or portable device is sized to match the expected bandwidth, from very low speeds at remote sites to very high speeds and thousands of TCP connections at hub-sites, different compression algorithms are used.

Small portable devices use a simple algorithm, while appliances with more CPU horsepower and significant memory capacity, can use a stronger algorithm that results in higher compression ratios. An active software resource manager balances these functions in real-time by making adjustments under very high load. In typical deployments, data compression is described as the function optimizing the transfer of data upstream and downstream at a rate that exceeds the link capacity. Bandwidth gain from data compression is variable, based on the type of data being transferred and the algorithm in use. Some files, such as office documents, text files, and non-image web objects, are highly compressible — as much as 400 percent, in some cases. On the other hand, TCP files such as zip archive files, executable binaries, and streaming video, will experience little benefit from data compression, but there’s no harm in trying.

Wireless Optimizers Meet QoS + Encryption
Whenever a PEP was deployed, network engineers generally found it necessary to manage the priority of the data to ensure the accelerated TCP data was not unintentionally causing packet loss on other applications such as Voice over IP (VoIP). As faster and more powerful hardware became available, PEP operations were merged with QoS functions, allowing operators to control and coordinate both activities on a single appliance.

Integrated quality of service features must scale in two dimensions to manage and control optimized data on public and private networks. On hub-site deployments, the QoS must support TCP rate controls and priority levels to hundreds or even thousands of remote sites. On the other end, remote sites typically need QoS to prioritize applications or users. Such ensures dedicated or shared bandwidth is properly allocated.


As satellite services expanded their reach to more and more areas of the world, many commercial network users began to implement IPSec to protect their organization’s data. When any type of encryption is used, network or modem based acceleration is effectively disabled, as the data passing through the optimizer is scrambled and unreadable. Modem wireless optimizers now include the ability to add IPSec encryption as a software option, further reducing the number of devices needed in each remote site. A modern wireless optimizer appliance will enhance TCP data and provide branch office QoS and IPSec in one device.

Another good example is cited in defense deployments. For military users today, bracketing the link outside the Type 1 Encryptors continues to be considered the best practice, meeting the networking and physical requirements for device isolation.

Going “One Way”
In the early days of satellite communications, end users were generally skilled in some aspect of networking and were often handling such tasks in military or research sites. However, as satellite communications became mainstream and encompassed many commercial markets, it became more common to find relatively unskilled, remote users attempting to install PEP equipment directly in the critical path of the satellite or wireless link, often in uncomfortable or hard to reach physical environments. In combination with the technical challenges of remote two-way site installations, also noted was a usage trend towards more of these links carrying basic Internet access traffic, sometimes serving entire isolated communities. These trends steadily led to the emergence of a new set of hub-site data compression solutions that operate only on Internet web content and require no hardware or software at the remote sites ­— they operate in a one-way mode.

One-way optimization is CPU intensive. At XipLink, Hub Optimizations (the XHO option) are offered only on high-end appliances, such as the XA-10K and XA-30K. This same device can simultaneously handle two-way SCPS connections for users with a remote optimizer installed, enabling SCPS acceleration and data compression for all TCP applications, particularly FTP in the upstream and downstream direction.

One-Way Hub-Site Optimizations
In traditional two-way SCPS deployments, each optimizer sends data from any TCP application using SCPS protocol acceleration and a common data compression algorithm, relying on the remote-site optimizer to decompress the data and to work with the sender to efficiently recover from packet loss. These algorithms have been carefully refined and tuned over many years and have resulted in a selection of operating modes specific to the various installation environments.


In one-way deployments, a single hub-site optimizer is configured with the Hub-Optimization software and is installed at the Internet point of presence — but no hardware or software is required at the remote sites. The device can be installed in-line as in traditional SCPS deployments, or the operator can use policy-based routing to direct select groups of users through the appliance.

The two primary functions in the Hub-Optimization software are:

• GZIP gateway — which compresses non-image web content in real-time
• Image Transcoding — a configurable real-time function that re-scans and encodes jpeg images to an operator defined quality that results in fewer bytes per image

The GZIP gateway operates on HTTP web page contents, compressing non-image web objects such as the index page, custom style sheets, Java scripts, etc., using the GZIP format. Standard web browsers then transparently perform the GZIP de-compression function prior to displaying the contents for the user. This is a lossless compression technique that eliminates the need for a remote device or proprietary plug-in software as GZIP compression is a standard function in today’s web browsers. Many web sites already GZIP compress their content in order to deliver their pages faster and more efficiently, however the Hub-Optimization function performs this in real-time for those sites that do not take advantage of this capability.

The second Hub-Optimization function, image trans-coding, is configured by the operator based on their accepted balance between bandwidth savings and image quality and is considered a real-time lossy compression scheme. JPEG images that are embedded in HTTP web pages are scanned in real-time and resaved at a “quality” metric specified by the operator. This function results in images that are the same physical size and same original pixel count, but at a reduced quality that results in far fewer bytes per image.


Simple Cost Savings
When the GZIP gateway and XiPix transcoding functions are used together, the bandwidth gains can be substantial. However, at some point the image quality will degrade to the point it becomes unacceptable. This setting is subjective and may be changed by the network operator in either direction, trading reduced image quality for more bandwidth, or using more bandwidth to preserve a higher quality image. XipLink has noted a significant willingness to use this function aggressively in areas where satellite or other wireless coverage is scarce, with no user objections so far.

In example, here’s the case of a VSAT operator in an area with limited coverage, trying to get as many users on the network as possible while maintaining acceptable performance and image quality. This indicates tuning optimization parameters will be moderately aggressive in order to save as much bandwidth as possible, but leaving the users with what is considered to be good image quality. For these calculations, the assumption is that the GZIP gateway and trans-coding functions are enabled in the one-way hub-optimizer.

In this author’s opinion, using an image quality setting of 20 will result in web page images that are quite acceptable, while still delivering significant bandwidth gains. Let’s use that setting in the model below...

What about voice?

By their very nature, PEP devices are designed to proxy a connection from one machine, over a wireless link to another machine, without user intervention or configuration. TCP is the connection-oriented protocol that is used to establish these connections, but the wireless optimizers are deployed in a key network location to address another area of optimization for connectionless protocols, driven by the growth of Voice over IP.

When these systems were originally deployed, the majority of Internet traffic was TCP/IP based, generally between web browsers and servers.

Today there are many more protocols riding across these links other than TCP, supporting all kinds of interesting applications. There is one application and protocol that has noticeably increased on almost every link XipLink encounters and that is Voice over IP that uses the UDP protocol. These UDP packets are typically very small, containing small voice samples that must be quickly sent in order to reproduce high-quality voice. The presence of this protocol by itself should not really be that interesting in light of a conversation around optimizing connection oriented sessions, but the fact there are so many of these packets arriving so rapidly due to their small size such has driven even robust modem vendors to request optimization of this protocol.

When many callers are off-hook, the network will experience very high UDP packets per second on the LAN, also explained as very tight packet arrival intervals, which can cause packets to be dropped at the modems LAN interface — designers simply could not have forecast how fast this application has taken off nor the implications of this technology to the mix of LAN data. As wireless optimizers are installed in-line, just upstream of any wireless modem, they are in a unique topology location where they can optimize this data as well as TCP, by the addition of a lightweight tunnel to the upstream site.

The two main components in these real time protocol optimizations are Packet Coalescing and Header Compression. When using packet coalescing, the wireless optimizer will wait a configurable time interval, aggregating UDP packets together, then transmitting many UDP packets over the wireless link as one larger “coalesced” packet, delivering a much more manageable packet per second rate to the modems.

The second function is specifically for the Real Time Protocol, where well-known algorithms can be applied, further reducing the number of packets required to send the same amount of voice data.

Wireless optimization vendors have come a long way and still have far to go. The adoption of CPU and memory technologies is certainly quick, as they continue to take leaps and bounds in efficiency.

Wireless optimization vendors must use those core technologies on hub-site appliances, making certain these devices scale to hundreds and thousands of remote users, but never forgetting the tight cost restrictions wireless customers expect. Wireless optimization vendors must also design software solutions that scale down, where very efficient algorithms must operate on smaller and smaller mobile devices in limited memory with busy mobile processors — there really are no alternatives to increasing bandwidth, so these functions must operate even on very small wireless devices.

Wireless optimization represents an evolution of early TCP performance enhancing proxy technology and represents a revolution for the application acceleration techniques that emerged from environments where large platforms in high performance chassis and large disk sub-systems were always assumed. Software efficiency remains a prime consideration once customers and partners understand these optimization solutions must be portable, mobile, and interoperable in both very large and very small form factors.