Satellite Optimization
Satellite Optimization
This chapter describes how to configure transport optimization for satellite networks. When you tune transport settings for satellite networks, you can achieve improved performance and interoperability with other TCP performance-enhancing proxies (TCP-PEP). Tuning transport settings for satellite networks falls into two primary categories:
•  Space communications protocol specification (SCPS) discovery - Provides interoperations with third-party TCP-PEP devices.
•  Transport settings - Provides flexibility for TCP optimization algorithms.
This chapter includes the following sections:
•  Overview of Satellite Networks
•  Overview of SCPS
•  TCP Optimization for Satellite Environments
•  Licensing SCPS on a SteelHead
•  Configuring Satellite Optimization Features
•  Verification and Troubleshooting
Note: If you are using a release prior to RiOS 7.0, SCPS was available through an RSP package and was not native to RiOS. The RSP SCPS package interoperates with SCPS native to RiOS 7.0. RSP SCPS package licenses are not valid for use as native RiOS SCPS licenses. Contact Riverbed Support or your sales team for assistance in converting RSP SCPS package licenses to native RiOS SCPS licenses.
Note: In RiOS 7.0.1 or later, RSP is replaced with VSP. VSP comes preinstalled in the SteelHead EX. For more information about VSP, see the SteelHead Management Console User’s Guide for the SteelHead EX. Your existing RSP packages work on VSP.
Overview of Satellite Networks
This section introduces satellite networks. This section includes the following topics:
•  Impact of Latency
•  Impact of Loss
•  Satellite Transport Options
You can use satellite networks for WAN connectivity for people in remote locations or when users are in a temporary or mobile environment (for example, a ship or an oil rig). Satellite networks have several characteristics that differ from terrestrial networks. The most prevalent differences include the following:
•  High latency
•  Dynamic bandwidth
•  Asymmetric bandwidth capability
•  Loss due to signal to noise issues
These characteristics can create challenges for traditional TCP algorithms for various reasons. This chapter helps you to understand and address these characteristics.
Impact of Latency
When it comes to TCP, latency is the enemy. The higher the latency, the longer it takes ordinary TCP to ramp up and use the available capacity. In satellite networks, latency is typically 10 to 100 times higher than in terrestrial links. Latency in a single-hop satellite network usually varies from 550 ms to 800 ms. Dual-hop satellite network latency commonly ranges from 1100 ms to 1600 ms. With Inmarsat BGAN networks (broadband satellite communications), it is not unusual to observe peak latencies of 2000 ms and higher when congestion is present.
Even though the SteelHead has TCP optimization enabled by default, tuning transport settings for a target satellite environment results in even better performance.
Impact of Loss
Satellite communications are known for having less than perfect packet delivery. Loss can wreak havoc on TCP throughput. If the loss is high enough, it can cause sessions to time-out. Loss can happen for several reasons on satellite networks. You must determine the primary cause of loss in your network so that you can tune your TCP optimization accordingly.
The two primary reasons for loss in satellite networks are congestion and poor signal quality. Do not ignore the possibility of a simple bad cable or speed and duplex mismatch when troubleshooting. Congestion-based loss is normal and expected when a link or path is saturated. Congestion-based loss triggers a TCP stacks congestion avoidance algorithm so that individual TCP sessions can adapt intelligently. Poor signal quality increases the bit error rate (BER), which is not due to congestion, but rather because of satellite communications. BER is independent of load on the circuit.
Many different events can trigger increased BER. A few of the most common are obstructions (buildings, bridges, and so on), a misaligned satellite dish, and weather. Weather events are temporary and go away in time. With obstructions or poor angles, the loss can be more persistent. Most satellite modems have forward error correction (FEC) built-in for free, and can overcome an increased BER in many situations.
In some cases, the BER loss is too severe for the satellite modem to overcome with FEC. In these situations, you might detect consistent TCP loss. Ideally, you should solve the root cause of the increased BER, but as a network administrator, this solution might be out of your control. In this situation, you can leverage a TCP Stack optimized for a high error environment.
Satellite Transport Options
You can choose from many satellite transport options. Their performance characteristics vary widely. A reasonable estimation is the more terminals sharing a segment, the higher the possibility for variable latency and loss. This section provides a brief summary of popular satellite solutions, along with general assumptions of loss and latency expectations. You should verify these details for your network because they might be different than those in the following table.
Satellite Transport Option
Variable or Fixed Throughput
Latency Characteristics
Loss Characteristics
Inmarsat BGAN
Highly variable—shared broadband
Highly variable
Highly variable
Single channel per carrier (SCPC)
Variable due to wait time for frequency slot
Variable due to wait time for frequency slot
Variable: certain codec modulations are adaptive and adjust to deal intelligently with poor signal quality.
Overview of SCPS
This section describes SCPS. It does not cover the implementation of SCPS on the SteelHead. This section includes the following topics:
•  SCPS Benefits
•  Common Uses for SCPS
•  SCPS and SteelHeads
For information about how to implement SCPS on the SteelHead, see TCP Optimization for Satellite Environments.
SCPS is a group of several protocol specifications developed by the consultative committee for space data systems (CCSDS) to address the limitations of communications in space. In the WAN optimization market, SCPS refers to the transport protocol specification, otherwise known as SCPS-TP. SCPS-TP is the most widely supported SCPS protocol. In the WAN optimization market, SCPS-TP is commonly called SCPS. The use of SCPS in SteelHeads is specifically referencing SCPS-TP. Definitions for all SCPS protocols are as follows:
•  SCPS-FP (file transfer protocol) - A set of extensions to FTP to make it more bit efficient and to add advanced features such as record update within a file and integrity checking on file transfers. This protocol is optional.
•  SCPS-TP (transport protocol) - A set of transmission control protocol (TCP) options, such as selective negative acknowledgment (SNACK), selective acknowledgment (SACK), modified slow start algorithms, modified congestion avoidance algorithms, and Windows scaling. Additionally, SCPS-TP includes sender-side modifications to enhance the TCP performance in the stressed environments, such as long delays, high bit error rates, and significant asymmetries. For flow negotiation, SCPS uses TCP options that are registered with the Internet Assigned Numbers Authority (IANA). As a result, the SCPS-TP stack is compatible with other recognized TCP implementations.
•  SCPS-SP (security protocol) - Based on security protocol 3 (SP3) and network layer security protocol (NLSP), with reduced protocol overhead of header. SCPS-SP also provides integrity, confidentiality, authentication, and access control for the data transmitted over the network. SCPS-SP is an optional protocol and is comparable to Internet Protocol Security (IPSec).
•  SCPS-NP (network protocol) - A bit-efficient network protocol that is analogous to IP. However, it is not compatible with IP. The protocol is designed for use in space systems. The protocol supports static or dynamic routing, precedence, and multiple routing options. This protocol is optional.
For more information about SCPS-TP, go to
SCPS Benefits
SCPS provides improved TCP performance in high-latency and high-loss environments, such as satellite networks. As a specification, SCPS enables third-party WAN optimization solutions that support SCPS, to provide TCP acceleration in a heterogeneous WAN optimization environment.
SCPS is designed for use in dual-ended proxy (symmetric) scenarios. However, some SCPS devices also provide single-ended optimization which enables a device to provide sender-side benefits even when there is no optimization appliance at the far end. However, not all SCPS solutions support single-ended proxy implementations.
Common Uses for SCPS
The three primary markets for SCPS are as follows:
•  Space agency space networks
•  Commercial satellite networks
•  Private government satellite networks
SCPS is a common request in large multiagency government satellite architectures in which a lowest common denominator approach to TCP acceleration is desirable. This enables the hub organization to provide basic TCP optimization to multiple agencies connecting into their teleports, without requiring a specific vendor solution.
SCPS and SteelHeads
SCPS is available in RiOS 7.0 or later. An SCPS license enables SteelHeads running RiOS 7.0 to negotiate SCPS optimization with another SteelHead or a third-party WAN optimizer or TCP-PEP. The SCPS license also enables the SCPS per connection and SCPS error-tolerant transport setting options. These two TCP stacks are tuned specifically for satellite networks. SteelHeads running RiOS 8.5 or later include a rate pacing mechanism to further tune the TCP. The mechanism can also negotiate compression with a third-party WAN optimizer or TCP-PEP.
You can configure transport optimization used by the SteelHead separately from SCPS negotiation. This separation provides extensive flexibility for a broad range of environments.
A SteelHead with SCPS, optimizing traffic to another SteelHead, uses the configured TCP stack and still performs standard RiOS optimization functions such as data reduction and application streamlining. The same SteelHead can negotiate SCPS with third-party TCP-PEP devices. This provides organizations with an approach for supporting third-party SCPS interoperability, while at the same time maximizing performance and productivity within their architectures with RiOS optimization.
For more information about using SCPS in SteelHeads, see TCP Optimization for Satellite Environments and Licensing SCPS on a SteelHead.
Note: In RiOS 7.0 or later, you must license SCPS and restart the optimization service to enable SCPS negotiation service. This is irrelevant of which transport optimization method you select (for example, standard TCP, high-speed TCP, BW estimation, per connection, or error tolerant).
TCP Optimization for Satellite Environments
This section introduces TCP optimization for satellite environments. This section includes the following topics:
•  SCPS Discovery
•  Transport Optimization for Satellite Environments
•  Configuring Automatic Detect TCP Optimization
•  Integrating the SteelHead with Existing Satellite Modem TCP Acceleration
TCP optimization enhancements in RiOS 7.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 7.0 or later fall into two primary categories:
•  SCPS discovery mechanisms
•  Transport optimization mechanisms
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 7.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 different from the RiOS 6.5 implementation of SCPS in RSP, which always uses SCPS transport optimization. The new approach in RiOS 7.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.
SCPS Discovery
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 - No Device
Client - SteelHead without SCPS
No acceleration
No acceleration
Client - SteelHead with SCPS
No acceleration
No acceleration
No acceleration
Transport Optimization for Satellite Environments
RiOS 8.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:
•  Bandwidth Estimation
•  Configuring Error Recovery
•  SCPS Per Connection
•  SCPS Error Tolerance
•  Rate Pacing
•  SCPS Single-Ended Rules
•  SCPS Compression
RiOS 8.5 or later supports four specific transport settings for satellite networks. These settings include three TCP stacks and an error recovery mechanism. The transport settings are included in the following:
•  Bandwidth estimation and error recovery are available in the base license of RiOS 6.5 or later.
•  SCPS per connection and SCPS error tolerance requires you to install an SCPS license in your SteelHead.
•  Rate pacing requires you to configure MX-TCP through advanced QoS.
For information about MX-TCP and QoS, see MX-TCP.
•  SCPS compression.
SteelHead transport settings are communicated among peers through the out-of-band connection between SteelHead peers.
Note: All RiOS TCP stacks support selective acknowledgments (SACK) for efficient retransmission of packets.
Bandwidth Estimation
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.
Configuring Error Recovery
To handle satellite transmission errors and intermittent connectivity, RiOS 6.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 modification 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.
To configure satellite transmission error recovery
•  Connect to the client-side (remote) SteelHead and enter the following command:
tcp err-recovery loss-recovery mode always
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.
SCPS Per Connection
The SCPS per connection transport setting uses a modified slow-start algorithm and a modified congestion-avoidance approach. This approach 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.
SCPS Error Tolerance
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 setting 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.
Rate Pacing
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.
Rate pacing 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
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 8.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: SCPS Single-Ended Rule as a Single-Ended Proxy 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.
Figure: SCPS Single-Ended Rule as a Single-Ended Proxy
For information about configuring single-ended rules, see Configuring Single-Ended Rules.
SCPS Compression
SCPS compression is available in RiOS 8.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.
Configuring Automatic Detect TCP Optimization
Automatic detect TCP optimization is in RiOS 7.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. TCP optimization 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.
To configure automatic detect TCP optimization
•  Connect to the CLI and enter the following commands:
tcp cong-ctrl mode auto
write memory
You can also choose Optimization > Network Services: Transport Settings, select Auto-Detect in the TCP Optimization box, and click Apply and Save.
Integrating the SteelHead with Existing Satellite Modem TCP Acceleration
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 autodiscovery does not work due to the satellite modem stripping the RiOS TCP option options used for autodiscovery.
For information about how to analyze for stripped probes, see Verification and Troubleshooting.
You can choose from several options to integrate SteelHeads with satellite modems conducting TCP acceleration. The options include:
•  Disable TCP acceleration in the satellite modems.
•  Enable TCP option forwarding in the satellite modem for the appropriate TCP options:
–  SCPS = TCP option 20
–  Correct Addressing = TCP option 76
–  Port Transparency = TCP option 76 and 78
–  Full Transparency = TCP option 76 and 78
•  Use fixed-target rules in the SteelHeads instead of autodiscovery. For more information about fixed-target in-path rules, see the SteelHead Management Console User’s Guide.
For information about how to disable TCP acceleration or configure TCP option forwarding, contact the satellite modem vendor technical support.
Licensing SCPS on a SteelHead
To determine if your SteelHead has a valid SCPS license, choose Administration > Maintenance: Licenses and look in the description column for SCPS. You can also use the show licenses command. The format of the actual license is LK1-SH55SCPS-XXXX-XXXX-1-XXXX-XXXX-XXXX.
When you order an SCPS license, it is delivered by email from You need a license for the data center and branch office SteelHead.
To install an SCPS license
1. Choose Administration > Maintenance: Licenses.
2. Click Add License.
3. Paste the license into the text field.
4. Click Apply.
Or, connect to the CLI and enter the following commands:
configure terminal
license install <license-key>
write memory
You must perform an optimization service restart to complete the installation of the SCPS license.
Configuring Satellite Optimization Features
This section describes the following tasks:
•  Configuring Transport Optimization
•  Configuring Rate Pacing
•  Configuring Single-Ended Connection Rule Table Settings
•  Configuring Single-Ended Rules
Configuring Transport Optimization
To properly configure transport settings for the target environment, you must understand its characteristics. This section describes how to configure, monitor, and troubleshoot the transport settings in RiOS 7.0 or later.
To capture your performance characteristics
1. Connect to the SteelHead CLI, using an account with administration rights.
2. Enter the enable mode and then configure terminal mode:
configure terminal
3. If your environment does not support path MTU discovery, use the ping command to measure the maximum transmission unit (MTU) by pinging a remote host.
Start with a full-size packet and decrease the size of the packet in small increments until the ping successfully reaches the target host.
Write the MTU here: ____________________________________
Write the round trip time here: __________________________
If you are deploying your SteelHead through WCCP, you might need to take into account the additional GRE overhead of WCCP. Use the following ping command for measuring maximum packet size along a specified path:
ping -I inpath0_0 -s <Bytes> <target host>
4. Use the following command with a full-size packet for a count of 1000 or more packets:
ping -I inpath0_0 -c 1000 -s <your MTU> <target host>
Write the percentage of loss during this test here: _______________
5. Configure the SteelHead WAN buffers for the target network.
Using the data you have collected, calculate two times bandwidth delay project (BDP) for your satellite network using the following formula or table. For satellite networks that vary in capacity, use the maximum potential speed the network can achieve. If your satellite link speeds differ in either direction, you might have different size send and receive buffer sizes. If this is the case, your send buffer on the transmitting side should match your receive buffer on the receiving side.
SteelHead WAN Buffers = ((Your RTT in milliseconds * 0.001) * (Your Circuit Speed in bps/8) *2)
For example, ((600 ms * 0.001) * (5,000,000bps/8) * 2) = 750,000 byte WAN buffers.
Use the following table as a quick reference to help estimate appropriate SteelHead WAN buffers.
Link Speed (bps)
RTT (ms)
Write the WAN buffer size, in bytes, here: ____________________________
6. Configure the satellite modem or router in the path with at least 1 BDP size buffer. This device is sometimes called the bottleneck buffer. Satellite modems might configure this satellite modem or router in terms of time such as milliseconds. In this case, the RTT provides the easiest measurement to use. Routers commonly configure this in terms of packets and thus 1 BDP/MTU gives the best approximation for the queue size.
Write the LAN buffer size, in bytes, here: ____________________________
For information about bottleneck buffer, see Potential Under Performance Due to Short Bottleneck Buffer.
To configure transport settings
1. Configure all the SteelHead WAN buffers with the following commands:
protocol connection wan send def-buf-size <buffer size>
protocol connection wan receive def-buf-size <buffer size>
Or, choose Optimization > Network Services: Transport Settings, select WAN and LAN receive and send buffers, and click Apply.
2. Configure your remote SteelHeads with the desired transport options from the commands in the following table.
Transport Optimization Option
Enable BW estimation
tcp-cong-ctrl mode bw-est
Enable error recovery
tcp-err-recovery loss-recovery mode always
Disable error recovery
tcp-err-recovery loss-recovery mode disable
Enable SCPS per connection
tcp cong-ctrl mode per-conn-tcp
Enable SCPS error tolerance
tcp cong-ctrl mode err-tol-tcp
Set back to default TCP
tcp cong-ctrl mode default
Or, choose Optimization > Network Services: Transport Settings, select the appropriate radio button, and click Apply (Figure: Transport Settings Page).
Figure: Transport Settings Page
3. If you have a mixed environment, configure your hub SteelHead to use automatic detect TCP optimization to reflect the various transport optimization mechanisms of your various remote site SteelHeads.
You can also hard code your hub SteelHead to the desired setting.
4. Restart the optimization service, either with the Management Console or the CLI.
Riverbed recommends that you test a few different transport settings, such as the WAN buffer sizes, at different remote sites and determine which settings work best for your environment.
For information about automatic detect TCP, see Configuring Automatic Detect TCP Optimization. For information about gathering performance characteristics and configuring transport settings, see the Riverbed Command-Line Interface Reference Manual and the SteelHead Management Console User’s Guide.
Configuring Rate Pacing
The following steps are required for rate pacing to function:
1. After you choose the transport option, select the Enable Rate Pacing check box in the SteelHead Management Console. You can also use the tcp rate-cap enable command.
2. Configure MX-TCP under Advanced QoS.
For more information about rate pacing, see Rate Pacing. For more information about MX-TCP and QoS, see MX-TCP.
The relationship between the overall link rate and MX-TCP rate dictates how the rate pacing mechanism operates. Rate pacing exits TCP slow start at the MX-TCP rate if the MX-TCP rate is less than the link rate. If you configure rate pacing in this way, it avoids the first loss on exiting slow start and uses MX-TCP as a scheduler for sending data while still adapting to congestion on a shared network in the congestion avoidance phase.
Alternatively, if the MX-TCP rate is greater than the link rate, then rate pacing exits at the link rate. This exit rate can incur a loss on exiting slow start, or packets are buffered in the bottleneck queue. The sending rate during congestion avoidance is based on a calculation between the rate the transport option (TCP stack) determines and the MX-TCP rate. Over time, the rate pacing mechanism continually probes for the higher MX-TCP rate.
In summary, the relationship works as follows:
•  Link rate greater than MX-TCP rate—Exit slow start at MX-TCP rate and maintain MX-TCP rate in congestion avoidance.
•  Link rate is greater than 50% of the MX-TCP rate but less than the MX-TCP rate—Exit slow start at MX-TCP rate and use the congestion avoidance rate determined by the underlying TCP stack selected as the transport option.
•  Link rate less than 50% of the MX-TCP rate or MX-TCP not enabled—Use the underlying transport option for exiting slow start and the congestion avoidance algorithm.
Because a hub site can be connected to multiple satellite networks and remote sites can use a variety of TCP stacks, it is appropriate for you to use automatic detect on the hub site for rate pacing. You can set up MX-TCP on a site-by-site basis to refine the data rate for each remote. MX-TCP follows the QoS configuration for matching on a site and rule.
The following example shows a configuration for the hub site for two remote sites using rate pacing with different bandwidths:
•  Site 1 has subnet and a link rate of 2 Mbps
•  Site 2 has subnet and a link rate of 8 Mbps
Use the following commands on the hub-site SteelHead:
tcp cong-ctrl mode auto
tcp rate-cap enable
Configuring Single-Ended Connection Rule Table Settings
Use the single-ended connection rule table to manage which flows are optimized or passed through for SCPS optimization. Configuration of the single-ended optimization rule table is similar to the in-path rules, but you must enable the single-ended connection rule table to apply the rules.
To enable the single-ended connection rule table
•  Connect to the CLI and enter the following command:
tcp sat-opt scps scps-table enable
You must have RiOS 8.5 or later to enable the single-ended connection rule table and SCPS compression with third-party WAN optimizers or TCP-PEPs.
To enable the single-ended connection rule table and SCPS compression with third-party WAN optimizers or TCP-PEPs
•  Connect to the CLI and enter the following command:
tcp sat-opt scps scps-table enable
tcp sat-opt scps legacy-comp enable
You can also complete the following procedure from the SteelHead Management Console Optimization > Network Services: Transport Settings page.
Figure: Transport Settings Page with Single-Ended Connection Rule and SCPS Compression
Enabling the SCPS single-ended connection rule table or SCPS compression requires a service restart.
To see the current rules in the table, use the show tcp sat-opt scps rules command. Following is an example single-ended connection rule table:
ssh (config) # show tcp sat-opt scps rules
Rule S P VLAN Source Addr Dest Addr Port
----- - - ---- ------------------ ------------------ --------------
1 Y Y all all all Interactive
2 Y Y all all all RBT-Proto
def Y Y all all all all
(S) SCPS setting: Y=Allow SCPS
N=SCPS Bypass
(P) Allow only SCPS peering: Y=Enabled
Rules are matched from top to bottom. A flow matching a rule stops at the first rule it matches and applies one of the SCPS modes: pass-through or enable. To pass through all flows for SCPS optimization, add a rule at the start of the table to match all sources, all destinations, all destination ports, and all VLANs.
To create a pass through all flows rule
•  Connect to the CLI and enter the following command:
tcp sat-opt scps rule srcaddr all dstaddr all dstport "all" allow-scps disable scps-peer-only disable rulenum start
Figure: Configure a Pass-Through Rule for All Traffic shows an example of a pass-through rule in the Management Console.
Configuring Single-Ended Rules
The following procedures show how to configure single-ended rules. Configuration of single-ended rules in RiOS 8.5 or later differs from configuration in RiOS 7.0 and 8.0. There are additional options available in single-ended rules: for example, using a single-ended proxy, enabling SCPS discovery or third-party integration and using rate pacing.
Figure: Single-Ended Rule with SCPS Per Connection and Rate Pacing shows an example of adding a single-ended rule configured in the SteelHead Management Console using SCPS per connection as the TCP stack and rate pacing enabled. You can use this configuration for when you interpolate with a third-party WAN optimizer or TCP-PEP and your network could benefit from using rate pacing with SCPS per connection as the transport option. Rate pacing requires that you configure MX-TCP with advanced QoS and MX-TCP only supports IPv4 traffic.
Figure: Single-Ended Rule with SCPS Per Connection and Rate Pacing
For more information about single-ended rules, see SCPS Single-Ended Rules. For information about configuring single-ended before RiOS 8.5, see earlier versions of the SteelHead Deployment Guide and Riverbed Deployment Guide on the Riverbed Support site at
To edit a single-ended connection rule
1. Choose Optimization > Network Services: Transport Settings page.
2. Expand the rule that you want to edit.
Figure: Edit Single-Ended Connection Rules
To add a single-ended connection rule
1. Choose Optimization > Network Services: Transport Settings page.
2. Select Add New Rule.
3. Populate the appropriate fields and settings.
4. Click Add.
The changes take place immediately to all new flows.
Figure: Configure a Pass-Through Rule for All Traffic shows how to configure a pass-through rule for all traffic. Clear the SCPS Discover and TCP Proxy check boxes.
Figure: Configure a Pass-Through Rule for All Traffic
Figure: Single-Ended Optimization Pass-Through Rule, Rule 1, shows an example of a single-ended optimization pass-through rule for all traffic initiated from the client-side SteelHead.
Figure: Single-Ended Optimization Pass-Through Rule
The Management Console passes through only locally initiated sessions through the LAN interface. Inbound SCPS sessions (SYNs with SCPS negotiation headers) arriving at the WAN interface are terminated. To bypass these inbound SCPS sessions, use the CLI. To pass through inbound SCPS sessions in the single-ended connection table, use the syntax option scps-peer-only disable.
Verification and Troubleshooting
This section describes common satellite deployment problems and solutions. This section includes the following topics:
•  Analyzing Connection Optimization Information
•  Analyzing Packets for Discovery Probe Stripping
•  Understanding the Health of the Satellite Signal
•  Potential Under Performance Due to Short Bottleneck Buffer
•  Potential Performance Impact of Loss at the Start of Flow
•  Variance in SCPS Performance
Analyzing Connection Optimization Information
After you configure the SteelHead transport settings, you can verify if the solution is working as expected. You can determine which transport optimization method a connection is using on the Current Connections page in the Management Console and the CLI. This section includes the following topics:
•  Using the SteelHead Management Console to Investigate Connection Details
•  Using the Riverbed command-line interface to Investigate Connection Details
Using the SteelHead Management Console to Investigate Connection Details
The Current Connections page in the Management Console provides extensive information about flows observed by the SteelHead. You can efficiently determine various information about flows using this report. To see the details for a flow, including transport settings, click the magnifying glass icon next to a specific connection.
Figure: Current Connections
Figure: Connection Information shows the details of a specific connection. This flow is optimized and the Congestion control indicates SCPS per connection, which confirms it is using SCPS. The SCPS Initiate is set to WAN, which indicates that this SteelHead is on the client side of this session. If the SCPS Terminate is WAN, then this SteelHead is the server side for the flow. The SCPS Initiate and Terminate cannot both read WAN, because a TCP flow can be initiated only in a single direction. The WAN Congestion Control indicates the transport setting.
Figure: Connection Information
If the current connections report has a lot of flows, you can filter your view. To see only single-ended optimization flows, show All current connections, add a filter, and in the drop-down list select that are single-ended only as shown in Figure: Filtering Flow View.
Figure: Filtering Flow View
Using the Riverbed command-line interface to Investigate Connection Details
The CLI provides extensive information about flows observed by the SteelHead. The show connections command provides a summary list of the connections flowing through a SteelHead. You can use this command with SCPS to quickly see which flows are optimized (O), single-ended optimized (S), and which flows are pass-through (P, PI, PU). Singled-ended optimized flows are included in the established optimized flow total of the show connections command. If you want more detail, use the show connections optimized full command. See the following examples for details.
SH # show connections
T Source Destination App Rdn Since
SO TCP 0% 2013/07/01 05:26:03
SO TCP 0% 2013/07/01 05:26:03
SO TCP 0% 2013/07/01 05:26:03
SO TCP 0% 2013/07/01 05:26:05
SO TCP 0% 2013/07/01 05:26:05
SO TCP 0% 2013/07/01 05:26:05
SO TCP 0% 2013/07/01 05:26:05
SO TCP 0% 2013/07/01 05:26:05
SO TCP 0% 2013/07/01 05:26:05
All V4 V6
Established Optimized: 9 9 0
RiOS Only (O): 0 0 0
SCPS Only (SO): 9 9 0
RiOS+SCPS (RS): 0 0 0
TCP Proxy (TP): 0 0 0
Half-opened optimized (H): 0 0 0
Half-closed optimized (C): 0 0 0
Establishing (E): 0 0 0
Pass Through: 0 0 0
Passthrough Intentional (PI): 0 0 0
Passthrough Unintentional (PU): 0 0 0
Forwarded (F): 0 0 0
Discarded (not shown): 0
Denied (not shown): 0
Total: 9 9 0
For more detail, use the show connection command options. The syntax requires very specific inputs, and it must be executed while the flow is established through the SteelHead:
show connection srcip <ip address> srcport <port> dstip <ip address> dstport <port>
You can look at the IP address and port requirements in the show connections flow table. An example of this command follows. The TCP congestion control mechanism is listed in the middle after WAN visibility mode:
SH # show connection srcip srcport 49588 dstip dstport 80
Connection not found.
SH # show connection srcip srcport 49597 dstip dstport 80
Type: Single-ended optimized
Optimization Policy: None
Application: TCP
Reduction: 0%
Since: 2013/07/01 05:27:19
Cloud Acceleration State: None
Source Side Statistics:
TCP Congestion Algorithm: Skipware Per Connection
Bytes: 328301
Packets: 273
Retransmitted: 0
Fast Retransmitted: 0
Timeouts: 0
Congestion Window: 235
Destination Side Statistics:
TCP Congestion Algorithm: New Reno
Bytes: 328301
Packets: 105
Retransmitted: 0
Fast Retransmitted: 0
Timeouts: 0
Congestion Window: 4
In most situations, it is easier to use the Current Connections page rather than the CLI for flow investigation. For details, see Using the SteelHead Management Console to Investigate Connection Details.
Analyzing Packets for Discovery Probe Stripping
RiOS autodiscovery and SCPS both rely on TCP options to function properly. Some network devices might strip the TCP options and negatively impact discovery or SCPS. In satellite environments, the satellite modems can have TCP acceleration enabled, which might strip TCP options and prevent the SteelHeads from automatically discovering one another.
This section describes how to troubleshoot this issue. You can confirm that TCP options are being stripped by capturing the SYN and SYN/ACK packets on the WAN interface of the server-side SteelHead and looking for TCP options decimal 76 or 78 or both. If you are using SCPS, also look for TCP option decimal 20.
On the server-side SteelHead, you can use the following commands to capture only SYN and SYN/ACK packets for the wan0_0 interface:
tcpdump -i wan0_0 -s 150 -w myfilename.cap 'tcp[13] & 2 = 2'
Note: Press Ctrl+C to stop the packet capture from the CLI.
You can also execute and stop the capture in the Management Console Reports > Diagnostics: TCP Dumps page. From this page, you can download the capture file. If you are running RiOS 7.0 or later, you can use Pilot Enterprise to remotely start, stop, and analyze packet captures.
After you have downloaded the capture file, open it with a packet analyzer.
If you are using Wireshark 1.6.1 or later to analyze packets, the information row in the Pack List pane begins with S+ or SA+ if a RiOS autodiscovery probe is present in the TCP option field of a SYN or SYN/ACK, respectively. If you have many packets, use the Wireshark display filter tcp.options.rvbd.probe==1 to display packets with RiOS discovery probes in the TCP option field.
To filter just for SCPS TCP options, use the display filter tcp.options.scps==1. Remember that SCPS TCP options are applied to only SYN or SYN/ACK packets. To filter for both RiOS and SCPS discovery probes, use the Wireshark display filter tcp.options.rvbd.probe==1 || tcp.options.scps==1. If you do not see any packets with RiOS or SCPS discovery probes, you likely have satellite modems stripping the TCP options field due to TCP acceleration.
After you select the desired packet, inspect the TCP option field to confirm that if the appropriate discovery probes are present. If they are not present at the server-side SteelHead, some device is stripping the probes: for example, a satellite modem or firewall.
Figure: Packet Information in Wireshark shows that the SYN packet (#16) is highlighted in Wireshark. In the Packet List pane, the Information column starts with S+, which denotes that the packet has a RiOS discovery probe in the TCP option field. In the Packet Details pane, the TCP option entry from the SteelHead is highlighted in gray, and the details of the probe are decoded. In the Packet Bytes pane, you can see that the actual bytes for the RiOS discovery probe are highlighted and begin with 4c (0x4c is the hexadecimal representation of decimal 76).
Figure: Packet Information in Wireshark
If you use Wireshark often to analyze SteelHead performance, you can use color filters to differentiate traffic.
To create Wireshark color filters
1. In Wireshark, choose View > Coloring Rules.
The Coloring Rules dialog box opens.
2. Click New.
3. Create a filter name, enter the desired display filter, and set your desired colors.
4. Click OK.
You can move the new color rule up or down so that it matches traffic accordingly. Remember that the first coloring rule that is matched is applied to the packet, so the order of color rules is very important.
Understanding the Health of the Satellite Signal
Terms such as such as signal-to-noise ratio, TDM loss, and other satellite words and abbreviations might be foreign to you. To assist in troubleshooting, you should have a team of satellite experts in your NOC or your service provider's NOC/teleport. When you contact them, the primary questions you want to understand are:
•  What is the utilization of the remote site's channel?
•  What is the bit error rate for the specific remote site, and is it within an environment's comfort zone?
To analyze a problem, most satellite engineers have a management tool available to track performance. For example, you can use iDirect iMonitor to monitor the health of iDirect hub and remote equipment. Using iMonitor's SATCOM view, you can track performance on a satellite link for an individual remote on the upstream and downstream channels. Figure: SATCOM shows a graph from the SATCOM view in iDirect iMonitor.
Figure: SATCOM
Having your own network monitoring equipment to monitor TCP health, specifically TCP loss/retransmissions, provides an additional tool in the network infrastructure to monitor network health. Riverbed Cascade, NetShark, and Pilot are capable of monitoring these metrics at various granularities.
Potential Under Performance Due to Short Bottleneck Buffer
The bottleneck buffer in the path is most commonly associated with the device connecting to both the high-speed LAN and lower-speed WAN. This device is responsible for absorbing the high rate of packets from the LAN and holding them until these packets can be transmitted over the WAN. Because this device can hold packets the size or length of this buffer, it can have an impact on performance. Remember that the bottleneck buffer can be a satellite modem or a router in the path.
Figure: Small-Sized Buffer shows the bottleneck buffer configured with a buffer size equivalent to 20 milliseconds when the link speed is 2 Mbps with an RTT of 550 milliseconds. The graph shows loss occurs early in the connection and is consistent throughout the connection. A perceptible one RTT gap can be noticed.
Figure: Small-Sized Buffer
After the buffer size has been changed, a different pattern emerges. The SteelHead can send data at a continuous rate to fill the WAN circuit. The loss that occurs is normal due to TCP continually detecting if there is a higher available rate.
Figure: Proper-Sized Buffer
Potential Performance Impact of Loss at the Start of Flow
TCP flows are most vulnerable to loss at the beginning of the flow. This loss is due to the initial TCP window size, which is very small at startup. When a TCP flow detects a lost packet in the first several turns, it can negatively impact the acceleration of the flow. Due to the latency in satellite networks, when this occurs, some TCP stacks take significantly longer to recover and accelerate the flow up to a reasonable speed.
When testing in labs, it is very important that you execute adequate flows against each test so that you capture a valid statistical sampling. This testing is critical because loss that coincidentally occurs at the start of flow negatively influences a single test for a certain vendor (Vendor A). Whereas the same test for Vendor B might not realize loss at the beginning of a flow, it might perform much better due to where the loss occurred, relative to the flow's life, and not specifically due to a more superior technology.
Variance in SCPS Performance
You might find that the TCP stacks of third-party SCSP solutions vary significantly. These variations can lead to different performance results when running the same transaction or test. When interoperating, you can find variance in performance between third-party devices, or variance depending on the direction data is transmitted. If you have questions or concerns about variance between SCPS solutions, it is best to engage all vendors in a joint discussion. Riverbed recommends that you have device configurations and packet captures from all devices to analyze during the discussion.