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:

This chapter includes the following sections:

This section introduces satellite networks. This section includes the following topics:

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:

These characteristics can create challenges for traditional TCP algorithms for various reasons. This chapter helps you to understand and address these characteristics.

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.

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.

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.

This section describes SCPS. It does not cover the implementation of SCPS on the SteelHead. This section includes the following topics:

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:

For more information about SCPS-TP, go to http://public.ccsds.org/publications/archive/714x0b2.pdf.

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.

The three primary markets for SCPS are as follows:

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 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.

This section introduces TCP optimization for satellite environments. This section includes the following topics:

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:

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.

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.

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:

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:

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 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.

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 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.

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.

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 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.

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

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.

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.

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 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:

For information about how to disable TCP acceleration or configure TCP option forwarding, contact the satellite modem vendor technical support.

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 riverbed-license@riverbed.com. You need a license for the data center and branch office SteelHead.

Or, connect to the CLI and enter the following commands:

You must perform an optimization service restart to complete the installation of the SCPS license.

This section describes the following tasks:

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.

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.

The following steps are required for rate pacing to function:

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:

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:

Use the following commands on the hub-site SteelHead:

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.

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.

You can also complete the following procedure from the SteelHead Management Console Optimization > Network Services: Transport Settings page.

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:

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.

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.

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 https://support.riverbed.com.

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: 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.

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.

This section describes common satellite deployment problems and solutions. This section includes the following topics:

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:

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: 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.

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.

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.

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:

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:

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.

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:

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).

If you use Wireshark often to analyze SteelHead performance, you can use color filters to differentiate traffic.

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.

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:

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.

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.

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.

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.

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.

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.