TCP Optimization for Satellite Environments

TCP optimization enhancements in RiOS v7.0 or later provide a robust and easy-to-use set of TCP optimization options for satellite networks. These mechanisms are specifically tuned for the performance challenges of satellite environments. The capabilities in RiOS v7.0 or later fall into two primary categories:

To use SCPS discovery or the SCPS transport options, you must install an SCPS license on the SteelHead. All non-SCPS options described in this chapter are included with the basic RiOS licenses, which include bandwidth estimation transport optimization and error recovery mode.

In RiOS v7.0 or later, the SCPS discovery advertises support for SCPS negotiation. SCPS discovery does not determine the TCP stack used during optimization. The transport optimization setting you configure on the SteelHead determines the TCP stack used during optimization. This is a different from the RiOS v6.5 implementation of SCPS in RSP, which always uses SCPS transport optimization. The new approach in RiOS v7.0 provides more flexibility for complex dynamic environments, and is also easier to use.

The separation of SCPS discovery and the transport optimization setting is a subtle point, but it is important to understand when you implement SteelHeads within a satellite environment with SCPS requirements. The remaining subsections provide more information about SCPS discovery and transport optimization settings.

This section describes SCPS discovery, also known as SCPS negotiation. SCPS discovery uses TCP options for discovery. SCPS uses a 4-byte TCP option with the decimal number 20 (hexadecimal 0x14). SCPS header also has extended capabilities that use a 10-byte TCP option with the decimal number 20 (hexadecimal 0x14). When you use the extended SCPS header, it immediately follows the mandatory 4-byte SCPS header. SteelHeads licensed for SCPS support dual-ended proxy connections to SteelHeads, and dual-ended proxy connections to third-party SCPS TCP-PEP devices. Keep in mind that the congestion-avoidance algorithm determines how TCP is optimized; SCPS discovery is only used for negotiating SCPS interoperability.

Client-side SteelHeads initially mark the SYN packet with the RiOS discovery TCP option (decimal 76 or 78). If no RiOS discovery response is detected in the initial SYN/ACK, then an RST packet is sent and a new SYN is sent with an SCPS TCP option. The new SYN uses the same client and server ports as the original SYN but has a different TCP sequence number. If an SCPS TCP option is returned in the SYN/ACK from the server-side peer, SCPS optimization is established.

If no SCPS TCP option is returned from the server side, a client-side SteelHead using SCPS does not optimize the flow and passes the traffic through. If you do not want SCPS optimization for specific traffic, you can use the single-ended connection rule table to exclude it. The following table summarizes the discovery process used in the various device scenarios.


Device Location/Type	Server - SteelHead without SCPS	Server - SteelHead with SCPS	Server - SCPS TCP-PEP	Server - No Device
Client - SteelHead without SCPS	RiOS	RiOS	No acceleration	No acceleration
Client - SteelHead with SCPS	RiOS	RiOS	SCPS	No acceleration
Client - SCPS TCP-PEP	No acceleration	SCPS	SCPS	No acceleration

RiOS v8.5 or later has a broad set of transport options that you can use to adapt the TCP optimization for specific segments of your organization and respective performance characteristics. This section specifically addresses transport optimization in satellite networks. This section includes the following topics:

RiOS v8.5 or later supports four specific transport settings for satellite networks. These include three TCP stacks and an error recovery mechanism. The transport settings are included in the following:

SteelHead transport settings are communicated among peers through the out-of-band connection between SteelHead peers.

The bandwidth estimation transport setting uses an intelligent bandwidth estimation algorithm along with a modified slow-start algorithm to optimize performance in long lossy networks. These networks typically include satellite and other wireless environments, such as cellular networks, longer microwave, or Wi-Max networks. Bandwidth estimation is a sender-side modification of TCP and is compatible with the other TCP stacks in RiOS. The intelligent bandwidth estimation is based on analysis of both ACKs and latency measurements. The modified slow-start mechanism enables a flow to ramp up faster in high latency environments than traditional TCP. The intelligent bandwidth estimation algorithm allows it to learn effective rates for use during modified slow start, and also to differentiate BER loss from congestion-derived loss and deal with them accordingly. Bandwidth estimation has good fairness and friendliness qualities toward other traffic along the path.

To handle satellite transmission errors and intermittent connectivity, RiOS v6.5 or later includes the lossy link-error recovery mechanism. In a lossy environment, you can enable error recovery to modify the congestion avoidance algorithm of the underlying TCP stack. This causes the underlying RiOS TCP stack congestion avoidance algorithm to be less responsive to retransmissions: for example, duplicate ACKs. This can be quite effective in situations with BER loss. However, you might not want it in situations where loss is congestion-based. By making TCP less responsive to loss, you might cause congestion to worsen. Due to this trade-off, use caution when you enable error recovery, particularly in situations with coexisting traffic along a path. Riverbed recommends that you do not enable error recovery on terrestrial channels.

You can enable error recovery only from the CLI. Use the tcp err-recovery loss-recovery mode always command on the client-side (remote) SteelHead.

This enables lossy link error recovery on all traffic sent by this remote SteelHead. This configuration is communicated to a peer SteelHead so that the peer SteelHead can use error recovery when it sends traffic to the remote SteelHead. By default, error recovery is disabled.

To disable lossy link error recovery, use tcp err-recovery loss-recovery mode disable.

The SCPS per connection transport setting uses a modified slow-start algorithm and a modified congestion-avoidance approach. This enables SCPS per connection to ramp up flows faster in high-latency environments, and handle lossy scenarios, while remaining reasonably fair and friendly to other traffic. SCPS per connection does a very good job of efficiently filling up satellite links of all sizes. SCPS per connection is a high performance option for satellite networks.

The SCPS error tolerance transport setting uses a modified slow-start algorithm and a modified congestion avoidance approach. SCPS error tolerance requires many more retransmitted packets to trigger the congestion avoidance algorithm than the SCPS per connection. The assumption is that the environment in which you use SCPS error tolerance has a high BER and most retransmissions are due to poor signal quality instead of congestion. This enables SCPS error tolerance to efficiently maximize performance in high loss environments, without incurring the additional per-packet overhead of a FEC algorithm at the transport layer. SCPS error tolerance is a high performance option for lossy satellite networks.

Do not use SCPS error tolerance in clean networks, because it can be quite aggressive and compete unfairly with other traffic.

The rate pacing setting uses a modified slow start algorithm to intelligently switch to congestion avoidance without incurring the penalty of the first loss to exit TCP slow start. Additionally, the SCPS rate pacing mechanism maintains a steady data rate in congestion avoidance while efficiently adapting to congestion in a shared network.

This is a marked improvement over using SCPS per connection, SCPS error tolerant, or MX-TCP. SCPS per connection and error tolerant switch from slow start to congestion avoidance on the first loss event. MX-TCP does not adapt to congestion in a shared network and could cause congestion collapse in which senders continually retransmit data. The combination of an efficient mechanism to switch from slow start without incurring a loss event and the use of a steady data rate in the congestion avoidance phase enables the SteelHead to fill a satellite link while avoiding some loss from buffer overruns and buffer delay for latency-sensitive TCP traffic.

Rate pacing is an ideal setting for many networks. The combination of a tuned TCP stack for satellite environments and MX-TCP to control the rate eases the burden of calculating buffer sizes and making adjustments across the infrastructure.

Rate pacing requires you to configure MX-TCP and as a result does not support IPv6.

For information about how to configure rate pacing, see Configuring Rate Pacing.

SCPS single-ended rules provide an option to use a TCP stack that is tuned for satellite environments when communicating with a third-party WAN optimizer or TCP-PEP. SCPS single-ended rules is used most commonly for SCPS integration.

In RiOS v8.5 or later, SCPS single-ended rules are enhanced to provide additional options suited for more complex environments. One key addition is the ability to select a transport option (TCP stack) on a per-rule basis, allowing you to use the most appropriate TCP stack for a given environment. You can also enable the rate pacing functionality on a per-rule basis to further adjust the transport optimization to the environment. You can support IPv6 hosts. The default rule is to pass through connections for all IPv4 and IPv6 hosts.

You can use SCPS single-ended rules to take advantage of a single-ended proxy. This functionality can help where there is no WAN optimizer or TCP-PEP on the other side of the connection. Because this feature is a sender-side modification, it provides the most benefit when used at the side of the connection sending the majority of the data.

Figure 15‑1 shows an example of a single-ended proxy connection. In this example, the server-side SteelHead uses a single-ended rule to proxy the connection using SCPS per connection as the TCP stack.

For information about configuring single-ended rules, see Configuring Single-Ended Rules.

SCPS compression is available in RiOS v8.5 or later. SCPS compression is designed for scenarios in which the SteelHead is interoperating with a third-party WAN optimizer or TCP-PEP using SCPS single-ended rules. When you enable SCPS compression, the SteelHead negotiates SCPS compression functionality with the third-party device. Compression is performed across the TCP header and payload. The TCP header is compressed according to the SCPS-TP standard, and the payload uses LZ-based compression on a packet-by-packet basis. SCPS-compressed IP packets have a next-protocol value of 105, which can require changes to intervening security devices.

Automatic detect TCP optimization is in RiOS v7.0 or later. Automatic detect TCP optimization enables a SteelHead to detect the transport setting (in other words, the TCP stack) advertised by a peer SteelHead and implement the respective transport setting for the applicable TCP flows to the peer SteelHead. This is useful in complex topologies where several different types of networks terminate into a hub or server-side SteelHead.

Use automatic detect TCP optimization on the hub SteelHead to enable an organization that uses the best transport optimization for the respective network segment. You enable the TCP optimization you want on remote SteelHeads. Automatic detect TCP optimization is advertised to a peer via the out-of-band connection between the appliances. The transport setting is communicated by the client-side or server-side SteelHead. However, at least one SteelHead must support automatic detect TCP optimization; otherwise, each SteelHead uses its defined transport setting.

Use automatic detect TCP optimization when you have lower-speed terrestrial connected remote sites, high-speed data centers, and satellite sites all terminating into a SteelHead at an aggregation point: for example, a data center. When you enable automatic detect TCP optimization on the aggregation point SteelHead, and the desired transport settings on the remote SteelHeads, each network segment uses the appropriate transport setting.

You can also choose Optimization > Network Services: Transport Settings, select Auto-Detect in the TCP Optimization box, and click Apply and Save.

In some networks, the satellite modems might have built-in TCP acceleration and possibly even LZ compression. Typically, these solutions do not perform well as advanced WAN optimizers such as a SteelHead. However, when you deploy a SteelHead into an environment with TCP acceleration in the satellite modems, the challenge is learning if your modems have TCP acceleration enabled, and then determining the most appropriate integration method.

You might not be aware if the modems you have are providing acceleration service until you have deployed the SteelHeads, and auto-discovery does not work due to the satellite modem stripping the RiOS TCP option options used for auto-discovery.