Release 4.0.2
Copyright © 2013 XipLink Inc
All rights reserved. Reproduction in whole or in part without permission is prohibited. Information contained herein is subject to change without notice. The specifications and information regarding the products in this document are subject to change without notice. All statements, information, and recommendations in this document are believed to be accurate, but are presented without warranty of any kind, express, or implied. Users must take full responsibility for their application of any products. Trademarks, brand names and products mentioned in this document are the property of their respective owners. All such references are used strictly in an editorial fashion with no intent to convey any affiliation with the name or the product's rightful owner.
1. XipLink Optimization Technology Overview ... 1
1.1. Introduction ... 1
1.2. Background ... 2
1.3. The XipLink Advantage ... 2
1.3.1. Protocol Acceleration ... 3 1.3.2. Advanced Compression ... 3 1.3.3. Internet Optimization ... 3 1.3.4. Security ... 4 1.3.5. Quality of Service ... 4 1.3.6. XipOS ... 4 1.4. Supported Capabilities ... 4 1.4.1. TCP Acceleration Techniques ... 4
1.4.2. UDP Acceleration Techniques ... 4
1.4.3. Compression and Application Acceleration ... 5
1.4.4. Tunnelling Options ... 5
1.4.5. Network Appliance Benefits ... 5
1.4.6. Standards Support and Interoperability ... 5
1.4.7. RFC and TCP Enhancements Support ... 6
1.5. Document Overview ... 6
1.5.1. Conventions used in this Manual ... 7
2. Quick Start - XA Series ... 8
2.1. Unpacking and Box Contents ... 8
2.2. Placing the Optimizer in the Network ... 8
2.2.1. Physical Connections ... 9
2.3. Accessing the XipOS Web User Interface ... 10
2.4. Login ... 10
2.5. XipLink Setup Wizard ... 11
2.5.1. Welcome ... 11
2.5.2. Select Deployment Options ... 12
2.5.3. Configure Network Interfaces ... 13
2.5.4. Configure DNS ... 15
2.5.5. Configure Networks ... 15
2.5.6. Set Password ... 17
2.5.7. Apply Changes To Device Configuration ... 17
3. Understanding XipLink Optimization ... 18
3.1. Dynamic Transparent Negotiation of Optimization Capabilities ... 18
3.2. SCPS Protocol Acceleration ... 19
3.3. XipLink Transport Control (XTC) Modes ... 20
3.3.1. XTC - Fixed Rate Control Mode ... 20
3.3.2. XTC - Dynamic Rate Control Mode ... 21
3.3.3. XTC - Programmable Fixed Rate Control Mode ... 22
3.3.4. XTC - Enhanced TCP Mode ... 22
3.4. Additional TCP Protocol Acceleration Techniques ... 22
3.4.1. TCP Connection Fast Start ... 22
3.4.2. Acknowledgement Frequency Reduction (AFR) ... 23
3.4.3. Selective Negative Acknowledgments ... 23
3.4.4. Quality of Service ... 24
3.4.5. Streaming Data Compression ... 26
3.4.6. XipOS Tunnelling ... 28
3.5. XipLink Hub Optimizations ... 28
3.5.1. XiPix Image Compression ... 29
3.6. XipLink Real-Time (XRT) ... 29
3.7. Byte Caching ... 31
3.8. Packet Compression ... 31
3.8.1. Advanced Cellular Compression ... 31
3.9. Link Balancing and Bonding ... 32
3.10. Web Cache Communication Protocol ... 32
3.10.1. WCCP Deployments ... 33
3.10.2. WCCP Configuration Concepts ... 34
3.11. XipLink Wireless Optimizer Internals ... 40
3.11.1. Dynamic Socket Buffers ... 40
3.11.2. Burst Connection Handling ... 40
3.11.3. Installation Flexibility ... 41
3.11.4. Management and Monitoring ... 41
4. The XipOS Web Interface ... 42
4.1. Dashboard ... 42 4.1.1. Device Name ... 42 4.1.2. Interface Status ... 42 4.1.3. Service Status ... 42 4.1.4. Device Status ... 43 4.1.5. Sampling Rate ... 43 4.2. Main Menu ... 43 4.3. Applying Changes ... 44 4.4. Networking Setup ... 45 4.4.1. Mode ... 45 4.4.2. Interfaces ... 47 4.4.3. DNS ... 48 4.4.4. Routes ... 50 4.4.5. RIP ... 51 4.4.6. OSPF ... 52 4.4.7. BGP ... 53 4.4.8. DHCP ... 54 4.4.9. SNMP ... 55 4.4.10. WCCP ... 57 4.4.11. Redundancy ... 59 4.5. Optimization ... 62 4.5.1. Optimization ... 62 4.5.2. Networks ... 64 4.5.3. Service Assignment ... 70 4.5.4. Traffic Assignment ... 73 4.5.5. Lightweight Tunnels ... 76 4.5.6. Link Balancing ... 79 4.5.7. Web Cache ... 80 4.6. System ... 83
4.6.1. Support & Docs ... 83
4.6.2. Logs ... 83 4.6.3. Stats ... 84 4.6.4. Users ... 85 4.6.5. Time ... 86 4.6.6. Backup ... 87 4.6.7. Upgrade ... 88 4.6.8. Reboot ... 91 4.6.9. Files ... 92 4.6.10. Diagnostics ... 94 4.6.11. Debugging ... 95
5. Redundancy Deployment Options ... 96
5.1. Router mode Redundancy using CARP ... 96
5.2. Bridge mode with STP failover ... 96
5.3. Bridge mode with fail-to-wire ... 97
6. Monitoring and Statistics ... 98
6.1. Optimizer Montoring Tool ... 98
6.1.1. Graph Controls ... 99
6.2. Monitored Data Sets ... 99
7. XipOS Command Line Interface ... 101
7.1. Introduction ... 101
7.2. Factory Reset ... 102
7.2.1. Accessing the Factory Reset Menu ... 102
7.2.2. Factory Reset Menu ... 102
8. Advanced Upgrade Procedures ... 103
8.1. Manual Upgrade via CLI ... 103
8.2. Replacing the Compact Flash Card ... 103
8.2.1. Equipment Required ... 104
8.2.2. Procedure ... 104
9. Troubleshooting and Diagnostic Tools ... 107
9.1. Netconf Errors ... 107
9.2. System Logs ... 108
9.2.1. The System Log File ... 108
9.2.2. The Netconf Log File ... 108
9.3. Diagnostic Tools ... 109
9.3.1. netstat ... 109
9.3.2. Quality of Service Queue Control ... 111
10. Support ... 113
10.1. Support Resources ... 113
10.2. Return Procedures ... 114
10.3. Frequently asked Questions ... 115
11. Appendixes ... 118
11.1. XipLink Product Matrix ... 118
1.1. XipLink Interoperability between devices ... 1
1.2. XipOS ... 2
2.1. Placement of the Optimizer ... 8
2.2. XA-500 ... 9
2.3. XA-2000 ... 9
2.4. XA-4000 | XA-10K ... 9
2.5. XA-30K ... 9
3.1. Dynamically negotiated optimization ... 18
3.2. Unoptimized connections using standard TCP ... 19
3.3. XTC – Fixed Rate Control ... 20
3.4. XTC - Dynamic Rate Control Mode ... 21
3.5. XTC - Programmable Fixed Rate Control Mode ... 22
3.6. TCP Connection Fast Start ... 23
3.7. AFR and Selective Negative Acknowledgments ... 24
3.8. QoS Re-Prioritizes Traffic ... 25
3.9. Streaming Data Compression ... 27
3.10. Compression Samples ... 28
3.11. XRT Packet Coalescing ... 30
3.12. Basic Single Interface Mode WCCP Deployment ... 33
3.13. Basic Router Mode WCCP Deployment ... 33
3.14. WCCP Hub Deployment ... 34
3.15. WCCP Service Groups ... 35
3.16. Bridge at remote - Router at hub ... 41
4.1. Router Mode Redundancy Setup ... 60
5.1. Router Mode Redundancy Setup ... 96
5.2. Bridge Mode Redundancy Setup ... 97
1.1. SCPS-TP Capabilities ... 5
1.2. HTTP RFC's ... 5
2.1. Factory default IP addresses ... 10
3.1. XRT: Benefit of Coalescing Multiple Streams ... 30
3.2. XRT: Effect of Different Capture Window Sizes ... 30
4.1. Differences Between Router, Bridge and Single Interface Modes ... 46
4.2. XipOS SNMP Traps ... 56
4.1. Multi-Link / Multi-Site Network Example ... 66
9.1. netstat Active Connections ... 110
9.2. netstat -e DSB Output ... 110
9.3. Sample netstat -s -p scps Output ... 111
Technology Overview
1.1. Introduction
XipLink delivers wireless optimization technology in many flexible ways:
• The XE-Series provide portable optimization software for any BSD, Linux or Windows based devices. • The XE-104 is a preloaded single board computer optimizer.
• The XA-Series are scalable appliances that deliver optimization from 2 to 155 Mbps.
Wireless optimization functions described in this overview operate transparently between users communicating across any two wireless IP networks that have optimization installed. For example, users on an aircraft with XE-Series software embedded in the airborne satellite modem will have their traffic transparently optimized when the connection request encounters an XA-Series appliance installed at the service provider's hub site. Embedded XipLink software interoperates with any other XipOS enabled device.
Figure 1.1. XipLink Interoperability between devices
The challenges of wireless optimization for satellite and terrestrial communication links are significantly different from traditional WAN optimization controllers or application accelerators:
• Wireless is a medium that experiences much higher latency and loss. • The price per bit on wireless links, especially over satellites, is much higher. • The ROI on improved use of the capacity is short, often measured in months.
1.2. Background
XipLink Optimization Software algorithms originate with aerospace research originally intended to increase the communications throughput between spacecraft and the Earth. It was quickly recognized that these same techniques work equally well when optimizing the complete end-to-end wireless link from ground station to ground station. Researchers were also pleasantly surprised by the fact that the techniques had virtually no negative effects on traditional TCP-based applications.
This pioneering work resulted in standards from NASA and other space agencies collectively called the Space Communications Protocol Specification (SCPS) and, subsequently a standard named Interoperable Performance Enhancing Proxy (I-PEP). The SCPS (pronounced “skips”) specification combines recommendations for the use of several standard IETF TCP enhancements as well as methods for the dynamic and transparent negotiation of options like special TCP acknowledgement schemes and data compression. The I-PEP standard, which builds on SCPS, is designed specifically for satellite communication profiles but also enables the negotiation of innovative vendor proprietary algorithms. This was a primary intention of the standard, and remains a key to its continued use and recent compliance mandates by the U.S. Department of Defense.
While the IETF has introduced some standards for TCP improvement over the years, the SCPS based protocol, along with specialized wireless optimization algorithms originally designed by vendors for space communications, continue to deliver the most advanced wireless optimization capabilities available today. These same algorithms continue to find greater and greater use in commercial and military VSAT applications and function equally well over space segments and terrestrial wireless links.
XipLink Mission Statement
Our Mission is to leverage XipLink's proven software in our partner`s network solutions, enabling operators and users to optimize available wireless bandwidth for maximum data throughput at the lowest capital cost.
1.3. The XipLink Advantage
At the heart of the XipLink optimizers is our proprietary optimization system, the XipOS. This system encapsulates various components, each component playing a vital role in ensuring that you can achieve optimal data performance through your current wireless infrastructure, thereby ensuring a reduction in operational costs and an increase in end-user satisfaction. That's the XipLink Advantage!
Figure 1.2. XipOS
Prot ocol Accelerat ion Advanced Com pression Int ernet Opt im izat ion Securit y
Qualit y of Service (QoS)
1.3.1. Protocol Acceleration
The goal of protocol acceleration is to fill the available upstream and downstream bandwidth pipe. Standard TCP was not originally intended to operate over wireless connections. The following factors severely undermine the performance of standard TCP.
• Long propagation Delay. Long-delay channels require larger windows than what standard TCP offers, and a more accurate Round Trip Time (RTT) evaluation. In addition, cumulative ACKs and delayed ACKs are not well suited for long-delay environments. Finally, Slow Start and Congestion Avoidance prove to be rather inefficient in the presence of long propagation delays.
• Connection Asymmetry. Wireless communications are very often used to provide asymmetric bandwidth services that are intended for large-scale information consumption. Typical internet applications (e.g. FTP, WEB) require relatively low bandwidth from the user to the information provider (e.g. FTP or HTTP server) and relatively high bandwidth towards the user. This effectively means the downstream throughput (towards the user) is controlled by the rate of upstream ACK's (toward the server). Upstream congestion affects downstream throughput, even though there is plenty of downstream capacity available.
• High Error Rate. Wireless communications can be influenced by various external factors such as radio interference and weather. Standard TCP interprets packet loss as loss due to congestion and thus reduces the transmission rate, degrading throughput even further.
SCPS standards were implemented to add an advanced layer of transmission control for TCP communication thereby addressing the inherent problem with standard TCP flow control to ensure maximum throughput
XipOS provides further optimization through XipLink's proprietary transmission control extensions (XTC), while still conforming to the SCPS standards.
More information on XTC can be found in the chapter on XipOS Functionality.
1.3.2. Advanced Compression
XipOS uses streaming data compression to effectively compress the TCP payload. This has a two-fold advantage over per-packet compression. Primarily there are more compressible patterns available, creating a higher compression ratio. Secondly it efficiently uses the TCP window and thus reduces the number of packets transmitted. Please see the section on Streaming Data Compression for an in-depth discussion
1.3.3. Internet Optimization
There are three methods by which internet web traffic is optimized
• Domain Name Caching. Internet traffic is based on IP addresses, however most web page URL's use domain names instead of IP addresses. Internet applications like web browsers need to resolve domain names into IP addresses in order to communicate with servers. On high latency links the time required to resolve domain names causes further delays. The XipOS domain name cache saves the results of domain name resolutions, so that subsequent requests for a cached name can be spared a round-trip time. • Web Proxy (optional). The web proxy option is currently only available on the XipLink XA-4000C and XA-500C series optimizers. These models transparently cache all internet web data for a period of time. Subsequent requests for the same data are served directly out of the cache.
• XHO (XipLink Hub Optimization). This is a Hub Side only deployment which supports http compression and image transcoding through lossy compression. There is no requirement for
additional remote units although deploying a SCPS enable remote will provide further acceleration and optimization benefits.
1.3.4. Security
XipOS includes a basic firewall to protect your network from possible attacks, allowing you to specify port and/or address ranges that you want to allow or block. The network behind a XipOS device can also be protected via NAT.
1.3.5. Quality of Service
Quality of Service (QoS) delivers the ability to prioritise certain traffic types, such as VoIP and streaming media, above others like FTP transfers. Different locations can use dedicated and unique QoS queues to ensure that each location receives a guaranteed minimum committed throughput while also taking advantage of any available unused throughput.
XipLink's QoS implementation uses Hierarchical Fair Service Curves to prioritize, guarantee and control traffic based on user-defined policies.
1.3.6. XipOS
XipOS encapsulates all the above components and offers multiple forms of management and monitoring through a secure web interface, SSH and SNMP.1
XipOS is the foundation of all XipLink products, ensuring transparency and interoperability between XipLink devices or with any other SCPS-compliant I-PEP device.
1.4. Supported Capabilities
1.4.1. TCP Acceleration Techniques
• XTC Bandwidth Rate Control
• Bandwidth Rate Control / Non Use of Congestion Control. Rate can be modified in real time and can account for non-TCP traffic in the path
• Quality of Service via Fair Weight Queuing Algorithm • SACK support
• Selective Negative Acknowledgments (SNACK) • Fast Start (T/TCP)
• Acknowledgement Frequency Reduction
• Maximize throughput and fairness while minimizing latency • Packet overhead configuration (for IP-in-IP protocols) • Firewalling and NAT capabilities
• Inflight data volume control for TDMA Networks • DSCP reading/marking
• Black Hole Detection • Automatic traffic bypass
1.4.2. UDP Acceleration Techniques
• XRT (XipLink RealTime): UDP Packet Coalescing; Robust Header Compression (RoHC)
1.4.3. Compression and Application Acceleration
• TCP streaming data compression (only with bracketed deployments) • XiPix HTTP image transcoding (Optional)
• HTTP compression (Optional)
1.4.4. Tunnelling Options
• Lightweight IP Tunnelling (no licence requirements)
• Advanced Cellular Compression (ACC) (optional licence required)
1.4.5. Network Appliance Benefits
• Fail-to-wire support with certain hardware platforms • Bridge Mode redundancy via STP
• Router Mode redundancy via CARP • Configuration download/upload • Graphical redundancy configuration
• SNMP support with a defined MIB and trap generation • Support for routing protocols such as RIP, OSPF and BGP
• Support for load-balancing using WCCP hash assignment, with L2 or GRE forwarding • Easy to use web interface
1.4.6. Standards Support and Interoperability
SCPS-TP is internationally recognized as ISO recommendation 15893:2000 and Consultative Committee on Space Data Systems CCSDS 714.0-B-2 and MIL-STD-2045-44000 among others. It has been recommended as the standard technique for performance enhancement by the U.S. Department of Defence for MILSATCOM IP communications.
XipLink has been demonstrated to be Interoperable with the SCPS-TP standard.
Table 1.1. SCPS-TP Capabilities
SCPS-TP Capabilities
• Enhanced TCP (with latest recommendations)
• Rate Control / Non Use of Congestion Control. Rate can be modified in real time and can account for non-TCP traffic in the path. Quality of Service also supported via Weight Fair Queuing Algorithm. • Selective Negative Acknowledgments – Short SNACK (long SNACK not recommended)
• RFC 1644: T/TCP (also known as Fast Start) • Acknowledgement Frequency Reduction
• Default Source of Data Loss (DSDL). However rarely supported by link layer.
Essentially all SCPS-TP features are supported except for Best Effort Transport Service (BETS) which requires specialized applications. An API is also provided to control all of these capabilities, either through a system or socket interface. Use of enhancement can be selective.
Table 1.2. HTTP RFC's
RFC Title
RFC Title
RFC 2616 Hypertext Transfer Protocol -- HTTP/1.1
XipLink’s HTTP Acceleration and data compression are proprietary algorithms. Refer to the Whitepaper “Internet Over Satellite Optimization with XipLink” for further information.
1.4.7. RFC and TCP Enhancements Support
RFC Title
RFC 793 Transmission Control Protocol
RFC 1122 Requirements for Internet Hosts - Communication Layers RFC 1191 Path MTU Discovery RFC
RFC 1323 TCP Extensions for High Performance
RFC 1644 TCP Extensions for Transactions Functional Specification RFC 2018 TCP Selective Acknowledgment Options
RFC 2338 Virtual Router Redundancy Protocol
RFC 2488 Enhancing TCP Over Satellite Channels using Standard Mechanisms RFC 2581 TCP Congestion Control
RFC 2582 The New Reno Modification to TCP's Fast Recovery Algorithm RFC 2988 Computing TCP's Retransmission Timer
RFC 3135 Increasing TCP's Initial Window
RFC 3390 Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations RFC 3782 The New Reno Modification to TCP's Fast Recovery Algorithm
1.5. Document Overview
This rest of this manual is divided into the following chapters:
Chapter 2 Quick Start. Provides instructions on how to quickly set up and configure your XipLink device.
Chapter 3 Understanding XipLink Optimization. Explains the concepts underlying XipLink's optimization capabilities, giving you the information you need to make the most of your XipLink device. Chapter 4 The XipOS Web Interface. Contains detailed instructions on how to configure all aspects of your XipLink device through its web user interface.
Chapter 5 Statistics. Describes how to view statistical graphs of your XipLink device's performance. Chapter 7 Advanced Upgrade Procedures. Explains how to perform certain unusual upgrades that are not handled by the web UI's upgrade process.
Chapter 8 Troubleshooting and Diagnostic Tools. Contains information about how to work with web UI errors and the device's logs.
Chapter 9 Support. Explains how to contact XipLink's support department, or return a defective device. Also contains a list of frequently asked questions.
1.5.1. Conventions used in this Manual
The following icons appear throughout this manual.
A note contains important information you need to know in order to properly use your XipLink device.
A tip provides insight into a particular way of using your XipLink device.
An important note contains critical information that must be followed in order for your XipLink device to function.
This section of the manual will enable you to quickly get up and running. It is assumed that you have some knowledge on Network Topologies and Wireless setups. It is recommended that you read through the other chapters to get an overall insight on how this unit needs to be configured for your particular network topology.
2.1. Unpacking and Box Contents
Please verify that you have received the following within your package contents: 1. XA Unit
2. Power Cable
3. Network Cable (Cat 5 Ethernet cable)
4. Console serial cable (RS232 DB9 null modem cable) or USB to RS232 Cable 5. QuickStart leaflet to provide basic startup information.
When unpacking and handling the contents of the box please take all precautions against electrostatic discharge as this may cause permanent damage the equipment. Please note: any damage due to electrostatic discharge will void the product warranty.
2.2. Placing the Optimizer in the Network
In a typical installation the optimizer is placed in-line into the segment between the LAN network and the Wireless Modem.
Figure 2.1. Placement of the Optimizer
Unaccelerated passing through the optimizer from the LAN is proxied, compressed and accelerated then forwarded over Wireless interface. Any accelerated traffic arriving on the Wireless side is decompressed and then passed back to the LAN. It is important to ensure that the LAN side is always connected to either the Router or Bridge interfaces, and that the wireless equipment is connected to the Wireless interface, otherwise network throughput will be degraded or disrupted.
Other deployment options, including out-of-path configurations, are possible. See the section on Web Cache Communication Protocol for scenarios that rely on certain Cisco routers, or contact XipLink for other possibilities.
2.2.1. Physical Connections
All ports on the XA's are clearly marked for identification. Each unit contains a Serial Console port to which you can gain direct access to the unit's console using the included serial cable, See the section on Management through the CLI for more information.
Some units include a USB port, but these are currently not used.
2.2.1.1. Product Labels
Figure 2.2. XA-500
Figure 2.3. XA-2000
Figure 2.4. XA-4000 | XA-10K
2.3. Accessing the XipOS Web User Interface
To access the unit via the Web interface, you will need to make the device available on your PC's network, or you can connect the device directly to your PC's LAN port using the supplied Ethernet cable.
The factory default configuration of the device is as follows:
Table 2.1. Factory default IP addresses
Interface IP Netmask
Management 172.16.1.200 255.255.255.0
Wireless 10.0.0.200 255.255.255.0
Bridged Not Configured
Router 192.168.1.200 255.255.255.0
It is recommended that you initially connect to the device through the Management interface. This will allow you to configure the device's main network settings without having to reset your PC's IP address. To allow for minimum downtime, you may configure the device prior to installing it in-line on your network.
Steps to take
• Connect your PC to the management interface, either via a network or direct LAN cable.
• Reconfigure your PC/Laptop to any IP address on the 172.16.1.0/24 subnet (except 172.16.1.200, which is the device's default IP address). For example, use IP address 172.16.1.1 and netmask 255.255.255.0. Please refer to your PC operating system's instructions on how to configure your PC's IP address. • Open your web browser and point it to http://172.16.1.200/
For Crypto versions you will need to connect via a secure https connection on using https://172.16.1.200.
2.4. Login
Use the factory default user name and password to log in. User Name: admin
Password: xiplink
2.5. XipLink Setup Wizard
Configuration of your XipOS device is done through a secure web interface.
Please note that your web browser requires JavaScript support. It is recommended that your display supports a minimum resolution of 1024x768.
The web interface allows you to configure your device and view live statistics. When you first access the web UI you will be presented with the Quick Config Wizard that will guide you step-by-step through the basic configuration options. The unit will be operational once the Quick Config Wizard is complete. Further configuration refinements can then be made within the Networking Setup and Optimization areas of the main UI.
2.5.1. Welcome
Welcome and thank you for purchasing our XipLink product. Here you will be able to view and accept the license agreement. Please complete the required registration information before accepting the license agreement.
End User Licence Agreement
The use of this device and the installed software is subject to agreeing to the XipLink EULA. Before you can continue with the configuration of the device, you must read the agreement, complete the licensee details (see below), and accept the agreement's terms.
Agreement accepted by
Supply the name of the user who has accepted this license.
From organization
Serial number
This is the software serial number of your XipOS installation. It is different than the hardware serial number of the device.
License agreement accepted
Once you have agreed to the software license and completed the above details, you can click on this checkbox to accept the license.
On-Line Registration
Only Visible once agreement is accepted
Please register this unit as on-line registration assists us in supporting your device and enables us to send you notification of any future software updates.
Should you not have Internet access when first configuring the device, you may register the device any time by returning to this page and selecting On-Line Registration.
Open User Guide
If the PC you are using to configure the device also has Internet access, you can register the device on-line. On-line registration assists us in supporting your device and enables us to send you notification of any future software updates.
Should you not have Internet access when first configuring the device, you may register the device any time by returning to this page and selecting On-Line Registration.
2.5.2. Select Deployment Options
The deployment options specify the network topology in which this device is going to be used. To complete this section, you will need to know where and how this device will form part of your network: which IP addresses to use and preferably some form of network diagram. Please see the section Installation Flexibility for detailed information on this topic.
Router, Bridge or Single Interface
Designate this device as a router, bridge or running in Single Interface mode. Which to choose depends on your network topology and where the unit is physically located.
In Bridge mode the unit is transparent to the network and will pass traffic though without the source and destination being aware that the device is in their path.
In Router mode, the unit is assigned two IP addresses and traffic needs to be explicitly routed through these addresses. In Router mode you can also enable Network Address Translation (NAT). If you do, you need to specify which interface will do the NAT translation. For most NAT installations, this is the Wireless interface with a public IP address.
Single Interface mode allows you to connect only the Wireless interface through to the network and then via tunnelling you would route clients via this PEP. For detailed information refer to the Networking Mode section.
Management Interface
The Management interface on the device can be configured to act either as a management interface or as a hybrid RX/TX interface. The selection here depends on your particular deployment requirements: Select the "Use as additional (management) interface" option when the Management interface will be used to manage the device. Typically this is used for out-of-band management, to ensure that management traffic is separate from routed traffic for security reasons. SNMP monitoring and traps are often sent via this interface to a central Network Monitoring System.
Select the "Hybrid" option when you have two separate wireless channels, one for transmitting (TX) and once for receiving (RX). This is typically used for a remote deployment where you will have a dedicated SCPC transmission channel and a broadband shared downlink DVB channel. Terminating both channels in a single XipOS device does away with any requirement for an additional upstream router.
Hub or Remote
Is the unit deployed at a hub site that communicates with many remote XipLink devices, or is it deployed at a remote end point and only communicates with one other XipLink device? If XipLink devices are deployed on both sides of this device, you need to select Hub/Mesh.
Device name
For ease of reference and administration, you should configure a unique name for this device. This name is displayed in the web UI, allowing visual confirmation of the device being configured.
The name of the device must consist solely of alphanumeric characters without spaces or punctuation.
2.5.3. Configure Network Interfaces
This section allows you to configure the physical interfaces of the XipLink unit. You can enable or disable any interface, and also set various options for each.
Wireless interface. This interface always faces your wireless equipment. Accelerated/compressed traffic arrives on this interface to be de-compressed and forwarded to its final destination on the Routed interface.
Routed interface. Unaccelerated traffic is sent to this interface to be optimized before leaving the Wireless interface.
Management interface. This interface is primarily used for out-of-band management of the device. It allows you to reconfigure the primary interfaces without having to concern yourself with losing your connection to the device. Should you use a separate management network, you can reconfigure this interface to use a specific IP address on the management subnet. This allows you to manage and monitor the device through this interface without interfering with the core routed traffic. Firewall configurations can also prevent any management traffic through the main Wireless or Routed interfaces, thereby providing an additional level of security to the device.
Address Type
Static. Assign a fixed IP address to this interface. You also need to supply the netmask. DHCP. Obtain an IP address from a DHCP server on this interface's network.
None. Assign no IP address to this interface. This is only useful when the device is in Bridge mode.
Maximum Transmission Unit (MTU)
The MTU setting defines the maximum size of a IP packet that can be transmitted without fragmentation. Values can range from 576 to 1500.
Media
Defines the type of media that is connected to the Ethernet interface. The default is autoselect, which should work in most environments. If you connect the device to any network equipment that is manually configured, the auto-detection may not always work. It is then best to manually configure the media type to avoid conflicts.
VLAN
Default gateway
The default gateway is the exit and entry point in a particular network subnet. All traffic that is destined for another network will be routed via this Gateway IP address.
2.5.4. Configure DNS
The Domain Name System (DNS) translates domain names meaningful to humans into IP addresses that can be routed across the network. It is an IP address directory, similar to a telephone directory, that holds all the domain name to IP address translations.
DNS Servers
Here you need to configure the primary and secondary DNS server IP's that are reachable from this particular device.
Domain
You can also supply a default domain name. The device will use this domain to resolve "unqualified" host names (i.e. names without a '.' in them). This setting is optional and rarely needed.
This section allows you to configure the device with the basic characteristics of the Wireless interface's link. Please see the section on the Networks tab to fine tune the configuration for your environment.
Link Properties
Click the Edit Link Properties button to configure your wireless link's properties. You can also edit the properties of the "Unassigned" link, which is a catch-all for traffic that the optimizer does not accelerate. Normally the "Unassigned" link has the same properties as the wireless link.
The Maximum Transmit Bandwidth is the maximum speed at which the device will transmit data over the link, while the Maximum Receive Bandwidth is the expected maximum speed that the device will receive data from the link.
Bandwidth and rate values must be specified with a unit: • Mb = 1,000,000 bits per second
• Kb = 1,000 bits per second • b = 1 bit per second
These values can only be integer numbers (without commas); decimal points are ignored. The Link Round Trip Time is the total amount of time (in milliseconds) it takes for a packet to travel over the link in both directions. This critical value is used by the Rate Control algorithms and also ensures that sufficient buffer space is allocated to manage inflight data.
Network Properties
Select Standalone hub deployment if your optimizer is to be deployed as a pure XHO hub (i.e. without a remote XipOS device). Selecting this option disables SCPS acceleration and TCP-level compression. The optimizer still proxies all TCP connections, but only applies XHO optimizations to HTTP connections. If you have a hub where some sites have a remote XipOS device and others do not, you can override this setting on a per-site basis using a QoS queue for each site and configuring specific TCP optimizations on the Service Assignment tab.
If your optimizer is a pure XHO hub, only select Adjust settings for an external Optimizer/PEP if you have an upstream Performance Enhancing Proxy (PEP) installed between this optimizer's Wireless interface and the wireless transmission equipment. This is required for any PEP that creates spoofed connections, such as a web cache.
The 'Wireless' ethernet max speed setting controls the maximum speed of traffic on the Wireless interface. This is typically the speed at which the interface syncs to its switch. For example, set this to 1000Mb for 1000BaseTX Ethernet media.
2.5.6. Set Password
Please choose a password to access the device.
Supply the current password (the factory default password is xiplink) and provide a new password and confirmation.
The password score indicates the new password's strength. The higher the value the more difficult the password is to break. Use a password with numbers, a mix of upper- and lowercase letters and punctuation characters to get a high score. A score of at least 50 is recommended.
2.5.7. Apply Changes To Device Configuration
Please review all of your settings before applying the changes. Should the Apply Changes option not be available, you will first need to accept the license agreement before you can proceed.
The XipOS software distinguishes between the active "running" configuration and the permanent "startup" configuration that is loaded when the device reboots. This distinction lets you experiment with different configuration settings, and allows you to undo your changes by rebooting or power-cycling the device. When you apply your changes, by default they are saved to both the running and startup configurations. You can prevent the changes from being written to the startup configuration by de-selecting the "Also apply to 'startup' configuration" checkbox, which will mean that the changes will only be in effect until the device is rebooted.
The system saves your changes by first applying them to the running configuration. If this succeeds (and the "Also apply to 'startup' configuration" checkbox is selected) then the changes are saved to the permanent startup configuration. Should any failure occur while modifying the running configuration, the system will attempt to roll back the changes to the previous state, all UI changes will be kept intact so that you can edit the changes and reapply the configuration. To retrieve the original settings as was previously applied, you will need simply refresh the web browser to reload these settings.
When changing the IP address of the device, you will receive a popup to notify you to now connect to the newly configured IP address. This is particularly true when changing the IP of the interface through which you are currently connected.
Optimization
This chapter describes the techniques and features of XipLink's optimization technology. Understanding these concepts will help you get the most out of your XipLink product.
Unlike application accelerators or cache machines, which usually reside very close to the enterprise LAN and which communicate across many intermediate links, wireless optimizers are installed to closely bracket the wireless link.
XipLink is committed to standards compliance wherever possible, but in the interest of delivering the maximum wireless capacity XipLink also uses industry leading proprietary algorithms as explained below. The SCPS standard allows such vendor-specific extensions, and XipLink leverages this fundamental capability to rapidly deliver improved algorithms while remaining completely interoperable and transparent.
3.1. Dynamic Transparent Negotiation of
Optimization Capabilities
The XipLink optimizer transparently proxies every TCP connection. Following the SCPS standard, extended TCP options are exchanged between SCPS-enabled proxies during TCP connection establishment. These options, which are transparent to non-SCPS applications, allow for the negotiation of standard SCPS optimization capabilities on each connection.
In addition to standard SCPS capabilities, other enhancements such as selective negative acknowledgments (SNACK) and the use of XipLink high ratio data compression are also negotiated during TCP connection establishment, using standard SCPS extensions for vendor-specific options.
Figure 3.1. Dynamically negotiated optimization
The SCPS TCP options underlying optimization negotiation can be routed over any Layer 3 IP network. This is a key underlying principle in the XipLink system architecture, and allows XipLink to deliver optimization to users across any network topology without the need for awkward network configuration such as tunnels:
• TDMA satellite networks
• Point-to-point and point to multi-point networks • Hub and Spoke networks
• Networks that may be only partially installed
Once a hub site has an optimizer appliance installed, remote users that are XipLink-enabled, either by software embedded in their wireless device or by connecting through an optimizer on their LAN, get fully maximized throughput. Other users who are not XipLink-enabled continue to use standard TCP, but without optimization benefits.
Figure 3.2. Unoptimized connections using standard TCP
3.2. SCPS Protocol Acceleration
XipOS optimizes the transport layer for communications across a wireless link in several ways. The conceptual algorithms for protocol operations over the wireless air interface are based on the SCPS standard. XipLink’s implementation of TCP protocol acceleration also uses additional advanced algorithms that are the result of years of engineering and exacting simulation to ensure maximum use of the available bandwidth.
XipOS addresses the loss and latency of wireless communications by applying specialized wireless algorithms and other optimization techniques to fully and fairly utilize the available capacity. Standard TCP encounter several problems when used across a wireless link:
• Slow connection setup due to long delay (latency) • Slow discovery of the available wireless bandwidth • Erratic use of the available bandwidth
• Slow response to packet loss that occurs in the network
• Overreaction to packet loss at high bandwidths, dramatically reducing the output rate • Hard-coded parameters, such as window sizes, limit throughput
• Poor response to simultaneous packet loss in many data streams (holes) • Protocol header overhead inefficiently consumes available bandwidth • Considerable bandwidth required for acknowledgements
XipLink protocol acceleration algorithms mitigate these issues with a combination of approaches that work collectively to achieve the highest performance for each wireless environment.
Features of the XipLink TCP protocol acceleration module:
• Selective Negative Acknowledgment (SNACK). A loss recovery scheme that is highly efficient over wireless links and works with different congestion control algorithms to adapt to packet loss. • Acknowledgement frequency reduction. (AFR) A technique that lowers protocol overhead by 33%
• Dynamic window scaling. Algorithms that scale TCP windows with network load, removing any artificial limits on communication capacity.
• Large windows. Uses buffers that are larger than those of other devices in the network, ensuring that additional latency is not introduced.
3.3. XipLink Transport Control (XTC) Modes
XipLink offers the largest selection of highly tuned congestion control algorithms. These deliver the absolute maximum capacity over a wireless link when properly matched and configured for the network where the optimizer is installed.
XipLink Transport Control (XTC) modes are rate-control and congestion-control algorithms that maximize capacity on a wireless link, beyond the single congestion control mechanism offered in the SCPS standard. As a result, XipOS can deliver significantly more throughput when the rate control algorithm is properly matched to the wireless network where the optimizer or software is installed.
A very important concept when discussing rate control algorithms in wireless networks is to understand that the XTC mode may be different for a hub site versus a remote site even though they are operating on the same network.
For example, in a hub-and-spoke TDMA network, the high-powered hub site may be capable of transmitting at a fixed rate and so would be set to Fixed Rate Control mode, while the remote sites may experience general RF contention and lower RF power budgets and would therefore be configured in Programmable Fixed Rate Control mode or Dynamic Rate Control mode. Congestion control is always viewed from the perspective of the sending device and it is not uncommon to find the modes configured differently on either end of a wireless link in order to deliver the maximum capacity.
The following sections describe the XipLink Transport Control (XTC) modes and briefly explain when each is typically used.
3.3.1. XTC - Fixed Rate Control Mode
Fixed Rate Control mode allows the network operator to configure the outbound traffic rate to a fixed, maximum rate. Whether there is one connection or hundreds, the XipLink optimizer will shape the TCP output traffic to sustain this fixed output rate and hold it very close to that maximum.
One specific goal of this mode is to ensure that performance does not decrease as the round trip time (RTT) climbs.
Figure 3.3. XTC – Fixed Rate Control
Fixed Rate Control mode is perfectly suited to both ends of a dedicated link like Single Channel Per Carrier (SCPC) space segments, but can also be used on both ends of stable TDMA or even DVB-RCS networks.
In licensed or unlicensed terrestrial networks this algorithm is always recommended at the hub site and can often be used at remote sites in stable point-to-point networks such as those served by a CPE device and good antenna.
Fixed Rate Control mode is infrequently used in mobile devices due to the constantly changing signal-to-noise ratio (SNR) these devices encounter as they roam. Even when operating in a licensed spectrum, the very nature of a roaming mobile device and their limited RF power budgets make the bandwidth appear dynamic.
3.3.2. XTC - Dynamic Rate Control Mode
Dynamic Rate Control mode is the default congestion control mechanism for a SCPS connection. This mode is useful in several situations, such as:
• When the wireless traffic may be passing through one or more unknown service provider networks. • If there is limited buffering capability within the network.
• If an intermediate controller is policing the traffic. • When I-PEP interoperability is important.
Dynamic Rate Control mode uses proprietary techniques that dynamically discover the available bandwidth and then anticipate and reduce the output rate before congestive loss occurs.
XipLink Dynamic Rate Control mode is based on years of research and uses algorithms that are designed to operate best on wireless networks. Wireless optimizers configured to use this mode rapidly determine the available bandwidth and respond very quickly by either increasing or decreasing the TCP output when the available bandwidth varies. This rapid convergence is accomplished by calculating the buffering that occurs within the network using volume-based algorithms. The optimizer then rapidly controls the output TCP flow rate to ensure the smallest buffers are not overrun, which would cause packet loss.
Figure 3.4. XTC - Dynamic Rate Control Mode
Dynamic Rate Control mode is recommended when the available bandwidth is unknown or varies widely, often on dynamic TDMA or DVB-RCS networks, particularly at the remote sites. While not as effective at completely filling a stable link, in many wireless devices it is more important to constantly and quickly adjust the transmission rate for maximum capacity.
Dynamic Rate Control mode is also an alternative for links where a traffic shaper may exist in the path between two XipLink optimizers. The traffic shaper's policing would work against Fixed Rate Control mode, dropping optimized traffic that may appear on the network as an aggressive TCP sender holding a very high data rate.
3.3.3. XTC - Programmable Fixed Rate Control Mode
This XTC mode, Programmable Fixed Rate Control, allows the “available bandwidth” setting of a fixed rate link to be varied multiple times per second using the XipLink API. When a wireless modem or other external device is capable of determining when the bandwidth changes and can generate a message to XipOS, this mode permits co-ordination of the TCP output to match the available bandwidth across varying degrees of capacity. This function is becoming more and more important in policy enforcement around a device's spectrum usage as well as to keep up with Adaptive Coding Modulation (ACM) dynamics. Using Programmable Fixed Rate Control mode, an external device can vary the “available bandwidth” when it detects a change in the size or depth of its outbound link buffers or a change in the link's speed or modulation characteristics. The external device sets the new “available bandwidth” using the XipLink API. The optimizer software can throttle the TCP output up or down, maximizing the capacity across the link without driving the link to a loss condition due to buffer overflow or upstream network congestion.
Figure 3.5. XTC - Programmable Fixed Rate Control Mode
Full performance on dynamic bandwidth links can be achieved using this mode, but Programmable Fixed Rate Control mode requires software integration within an embedded system or external integration using the XipLink API. As such, this mode is only available with specific devices that support this capability. Programmable Fixed Rate Control mode can operate both at coarse intervals, as when a ship changes satellites as it moves across an ocean, and also very rapidly (sub-second) when tightly coupled with a device that aggressively monitors the available bandwidth.
3.3.4. XTC - Enhanced TCP Mode
This is a simple rate control algorithm that follows the basic TCP Reno recommendations for congestion control. It uses improved TCP slow start to react to packet loss. It is useful on stable links when Fixed Rate Control cannot be used due to an upstream QoS traffic shaper, similar to Dynamic Rate Control.
3.4. Additional TCP Protocol Acceleration
Techniques
3.4.1. TCP Connection Fast Start
Using TCP fast start technology, data can be included in the initial connection handshake. This combines in a single round trip both connection establishment and the first few bytes of data in the TCP connection.
Without TCP fast start, an application has to wait for setup request and acknowledgement to traverse the slow wireless link before sending any data.
A typical Internet user with a standard web browser may open several connections to many servers for each web page viewed. TCP fast start can significantly decrease the time needed for a page to load, and will also greatly reduce the amount of contention on the wireless network by decreasing the number of packets sent and reducing the overall bandwidth consumed.
Figure 3.6. TCP Connection Fast Start
XipLink’s fast start is based on our efficient implementation of IETF RFC 1644. Traditional TCP uses a 3-way handshake before data transmission can begin. If we consider a minimum ¼ second delay in each direction, just establishing a TCP connection to a server could require over ½ a second, even before requesting the first bits of data. The benefits of TCP fast start are most apparent when multiple connections are used together in sequence, such as with HTTP and other client-server applications.
3.4.2. Acknowledgement Frequency Reduction (AFR)
On asymmetric links, enabling AFR will reduce the number of acknowledgments the receiver will send back as data is received. When AFR is active, the XipLink optimizer will use a calculated “delayed acknowledgement time” based on the configured bandwidth and delay along with a proprietary XipLink algorithm. Standard TCP's “every-second-packet” acknowledgment framework was originally devised to sustain high speed LAN throughput. In contrast, with AFR the XipLink optimizer acknowledges a much large volume of data with a single packet.
When enabled, this feature can reduce packet overhead by 33% or more while sustaining maximum throughput across the wireless link. As the link speed increases, or when a communication link is highly asymmetric, protocol reduction benefits continue to increase while sustaining the maximum bandwidth capacity.
3.4.3. Selective Negative Acknowledgments
The Selective Negative Acknowledgements (SNACK) technique works in combination with Acknowledgment Frequency Reduction and allows for rapid response to packet loss. It is much more responsive than traditional TCP's packet acknowledgment scheme which has proven ineffective when applied to wireless links.
Using SNACK to communicate only those packets lost in transmission allows communications to continue even at very high error rates. This makes XipLink wireless optimization algorithms very resilient to rain fade and other RF related conditions while scaling to very high throughputs. SNACK is more
bit-efficient than Selective Acknowledgement (SACK) and is more effective against the multiple losses that are common with wireless interference.
Figure 3.7. AFR and Selective Negative Acknowledgments
SNACK is an important component of TCP protocol optimization in satellite and terrestrial wireless networks because the higher error rates experienced over wireless links magnify the effects of high latency on retransmissions.
3.4.4. Quality of Service
The XipLink wireless optimizer provides several Quality of Service (QoS) capabilities that work with both internal optimization functions as well as with network-wide QoS services.
All traffic, including traffic not slated for acceleration, still passes through a fast path in the XipOS kernel. Constantly monitoring all traffic passing through the optimizer ensures that it will not saturate the link with accelerated data, which might cause packet loss in unaccelerated protocols.
QoS connections that meet an operator's defined Differentiated Services criteria are given preferred access to the available bandwidth, ensuring that mission-critical or performance-sensitive applications receive the bandwidth they need.
Any XipLink wireless optimizer can also tag, mark or re-mark specific traffic as it leaves the device. This enables the network operator to deliver an end-to-end integrated QoS system using differentiated user classes or queues. This capability can be used to prioritize some traffic or limit the bandwidth used by others.
3.4.4.1. QoS Overview
Quality of Service allows you to classify packets that pass through the device and assign different priorities to different kinds of traffic. Without QoS, traffic passes through the device on a first-in first-out (FIFO) basis. This can degrade performance when the link becomes congested, and it also allows
bandwidth-hungry applications such as P2P or bulk file downloads to overwhelm the link and prevent the timely delivery of streaming or interactive protocols. These problems are compounded on links with high round-trip times.
Figure 3.8. QoS Re-Prioritizes Traffic
QoS also helps a hub site deal fairly with multiple remote "spoke" sites when each remote site can have its own downlink rate that differs from the hub site's uplink rate. With QoS you can configure the hub with a fixed maximum transmission rate for each remote site. This in turn allows each remote site to apply its respective downlink rate without causing congestion and limiting bandwidth to other remote sites.
QoS only applies priorities and shaping to traffic transmitted over the wireless link from the XipLink optimizer. The device has no way to control the rates at which it receives data (aside from standard TCP congestion control mechanisms, which do not differentiate types of traffic). QoS is therefore normally applied on both devices on either side of the wireless link to control how each device transmits data.
3.4.4.2. QoS Queues
XipOS uses the concept of QoS queues to define traffic priorities. Each queue has a parent and zero or more child queues. A special top-level (parentless) queue named root defines the total amount of bandwidth that can be transmitted from a device. (The root queue's limitations are set by the maximum bandwidth of the Wireless link.)
The root queue is a conceptual entity and is not exposed in the XipOS GUI.
The parent-child relationships between queues define how bandwidth is allocated among the queues. A queue cannot reserve more bandwidth that what has been reserved by its parent.
Each childless (or "leaf") QoS queue is associated with a firewall rule that defines what kind of traffic the queue controls.
The order of firewall rules is critical to successfully applying QoS.
One of the childless queues must be designated as the default queue. The default queue shapes all traffic that does not match any other queue. The default queue is the only leaf queue not explicitly associated with a firewall rule.
The Unassigned Queue
All XipLink optimizers have an "Unassigned" queue that acts as a catch-all for unclassified traffic that does not match any of the other queues. To lower the priority of unclassified traffic, configure the Unassigned queue with lower bandwidth properties than the other top-level queues.
In Single Interface mode, traffic sent to the LAN network is classified in the Unassigned queue.
3.4.4.3. QoS Algorithm
The XipOS queueing algorithm is based on Hierarchical Fair Service Curves (HFSC), with several adaptations for wireless and satellite links. HFSC allows proportional bandwidth distribution (supporting equal or unequal bandwidth sharing) as well as control and allocation of latency. Each QoS queue can be configured with three main bandwidth transmission parameters:
• Maximum transmission rate • Guaranteed transmission rate • Priority transmission rate
All queues in the hierarchy can have a maximum and a guaranteed rate. Leaf queues, since they are the only queues that actually hold packets, can also have a priority rate.
The maximum rate is simply an upper limit on the queue's sending rate. Whenever a queue reaches its maximum rate, no further packets can be sent by that queue until the rate subsides.
The guaranteed rate controls the queue's relationship with its siblings at the same level in the QoS queue hierarchy. This is the bandwidth guaranteed to a queue when the link is saturated, ensuring that traffic is distributed properly among the sibling queues. Separating the guaranteed and priority rates allows the system to meet priority delay times under all circumstances. It also means that a queue can send a packet to meet its priority rate even if doing so temporarily violates the guaranteed rate of one of its ancestor queues in the hierarchy.
The guaranteed rate of a given queue must be equal to or greater than the sum of the guaranteed rates of the queue's children. This ensures that all queues can achieve their configured guaranteed rates.
For example, if a queue has two children with guaranteed rates of 2Mbps and 3Mbps, then that queue must have a guaranteed rate of at least 5Mbps.
A queue's guaranteed rate can be specified either as an absolute value or as a percentage of its parent's guaranteed rate. A queue with multiple children can have some of its children specify their guaranteed rates as percentages and others as absolute rates.
The priority rate is filled first across all queues. In other words, if there is traffic available in several queues the system will first service the queues that have not yet reached their priority rates. Priority rates should not be oversubscribed. They are often used for real time protocols like VoIP, gaming and other latency-sensitive applications. XipOS queues also have a delay parameter that limits the amount of time a packet can spend in the queue. This allows fine control over jitter and the quality of streaming protocols such as voice calls.
3.4.5. Streaming Data Compression
In addition to optimizing the TCP protocol for transport over wireless links, XipOS also applies high-ratio data compression to the TCP payload. To achieve a high compression high-ratio the software performs
continuous compression on the entire stream of data for each on-going connection, taking advantage of the streaming nature of TCP.
Stream-based compression is superior to other payload compression strategies that compress data within individual IP packets. These older per-packet compression algorithms yield lower compression ratios and do not reduce the overall number of packets needed to send the compressed information.
Figure 3.9. Streaming Data Compression
XipOS stream compression algorithms are tuned to ensure that additional latency is not introduced through the buffering required for optimal data compression, which might lead to lower overall bandwidth utilization. Data compression is most effective when performed on larger data sets, because more patterns inside the data can be found and removed. However, if only a few hundred bytes of data are transmitted at a time, the data is briefly buffered before automatically being forwarded out the wireless port without waiting for more data - maintaining very low latency. The timers that ensure this balance between waiting time and data volume are based on years of real-world deployment and simulation experience.
A XipLink wireless optimizer will compress only the TCP payload, leaving the TCP headers in the clear. This allows TCP acceleration algorithms to operate on, and XTC rate controls to be applied to, the compressed data stream. This enables the wireless optimizer to transmit at the maximum output rate, as prescribed by the rate control settings, even as the compression ratio varies from packet to packet. Other compression strategies that can yield higher compression ratios but typically operate by putting all traffic into a common compressed tunnel. Such systems require end-to-end or tunnel based configurations, and are not well suited to wireless links because they limit network scalability and add packet overhead, all detrimental to maximizing capacity at low capital cost.
The compression ratio of a particular data stream is completely dependent on the nature of the data itself. Text - as found in web pages, email, etc. - is highly compressible while random data is not compressible at all. Internet video streams are generally very compressible while video from modern video surveillance systems is so well encoded by the camera there is not much left that can be compressed. It never hurts to run these streams through the compression module, but user expectations for compression ratios must be realistic based on the type of traffic being transmitted.
Figure 3.10. Compression Samples
Most XipLink customers see between a 40% and 300% compression ratio depending on the data itself and the usage patterns. In general, compression ratios average about 2:1, but this is an area of rapid technology innovation and improvements which will continue to yield higher and higher ratios on traffic that is not already pre-compressed.
3.4.6. XipOS Tunnelling
In today's dynamic networks, customers typically have minimal control of content proxying and filtering on their service providers' networks. When the XipOS is deployed in an environment where the optimizer is not placed in a hub or teleport, or when the intercommunication between the two XA's connect over the public internet, it is possible that TCP packets may be stripped of the SCPS or acceleration options added to the TCP headers. This effectively means that the acceleration options will not be negotiated between the various instances of XipOS.
To address these situations, XipOS provides a UDP tunnelling feature to protect acceleration options being stripped from the TCP headers. All traffic is optimized prior to being transmitted within this tunnel, so that the maximum capacity of the link can be obtained.
Tunnelling also enables remote installations of XipOS optimizers to operate behind a NAT firewall, or within a private network segment, or where the service provider only provides private IP addresses. Finally, tunnelling is required for XipLink Real-Time (XRT) optimization.
3.5. XipLink Hub Optimizations
Some XipLink optimizer models support hub-only optimizations (XHOs) that improve performance without the need to deploy a second optimizer on the other side of the wireless link. Hub optimizations provide benefits when they are enabled on the "upstream" or "Internet" side of a wireless link.
• XiPix web image compression.
• HTTP compression for browser-compatible decompression.
3.5.1. XiPix Image Compression
XiPix technology automatically reduces the resolution of web images on the fly, dramatically reducing image file sizes with only a minor impact on the user experience. XiPix compression is transparent to the end user, and is compatible with all other XipLink optimization technologies.
An operator can configure XiPix's level of compression, allowing you to specify the tradeoff between image size and quality.
XiPix technology only applies to JPEG images transmitted over HTTP. Most Internet web sites use JPEG-format images.
XiPix is a separately licensed capability, and can only be enabled with a valid activation code. Please contact XipLink to obtain an activation code.
3.5.2. HTTP Compression
XipLink's HTTP compression takes advantage of the standard compression capabilities defined in the HTTP protocol. All modern browsers support HTTP compression standards, but few web servers take advantage of it.
With XHO HTTP compression, a XipLink optimizer can automatically and transparently compress HTTP traffic that is not already compressed by the web server. The user's web browser will decompress the traffic, so there is no need to deploy a second optimizer on the user's side of the wireless link.
3.6. XipLink Real-Time (XRT)
XipLink Real Time optimizations compress and coalesce multiple small UDP packets to significantly enhance UDP bandwidth efficiency. Wireless products have inherent limitations to the number of packets per second they can process. XRT reduces the number of packets required to carry a given volume of real-time traffic.
How can UDP traffic benefit from XRT?
• Most VoIP traffic consists of headers - approximately 40%. • Most headers do not change much from packet to packet.
• Multiple streams each have their own overhead and many common headers.
• Inefficiencies apply to most UDP-based protocols, from standard VoIP and Skype to other small-packet applications such as Citrix.
• XRT does not alter the data payload in any way, so it does not rely on any particular VoIP codec or UDP application.
XRT is an extension of XipOS lightweight tunnelling. You must enable tunnelling in order to use XRT.
Packet Coalescing
Packet coalescing is a technique that combines the payloads of many small network packets into a single large packet that can be transmitted and processed more efficiently. The following figure illustrates how XRT packet coalescing reduces the effective packet-per-second rate of real-time traffic.
Figure 3.11. XRT Packet Coalescing
Packet coalescing is not merely applied on each connection between a client and server, but on multiple data streams between various hosts offering a greater benefit. The benefit is proportional to the number of data streams available for coalescing.
The table below illustrates the benefit of coalescing multiple VoIP streams.
Table 3.1. XRT: Benefit of Coalescing Multiple Streams
Codec & Bit Rate Capture Window # of calls Bandwidth Savings PPS Benefit Ratio G.729 (8 Kbps) 20 ms 1 8% 1 G.729 (8 Kbps) 20 ms 2 33% 2 G.729 (8 Kbps) 20 ms 5 47% 5 G.729 (8 Kbps) 20 ms 10 52% 10 G.729 (8 Kbps) 20 ms 20 54% 20 G.729 (8 Kbps) 20 ms 50 56% 50 G.729 (8 Kbps) 20 ms 100 57% 70 G.729 (8 Kbps) 20 ms 200 57% 70
These results were obtained under laboratory conditions. Actual results will vary based on the individual packet sizes in the data stream, the capture window size, and the maximum coalesced packet size.
Note the convergence towards a 57% bandwidth savings as more streams are coalesced.
The next table shows the impact of the capture window size on packet coalescing. Increasing the capture window size would increase the benefit, although it may also increase jitter if not enough UDP traffic is present.
Table 3.2. XRT: Effect of Different Capture Window Sizes
Codec & Bit Rate Capture Window # of calls Bandwidth Savings PPS Benefit Ratio G.729 (8 Kbps) 5 ms 10 37% 3 G.729 (8 Kbps) 10 ms 10 47% 5 G.729 (8 Kbps) 15 ms 10 50% 8 G.729 (8 Kbps) 20 ms 10 52% 10
