You can deploy SCPS connections using either a double-ended or single-ended topology. For a double-ended SCPS connection, appliances at both ends must support SCPS. This setup enables full optimization, including SDR (Scalable Data Referencing) and LZ (Lempel-Ziv compression). All licensed product features are supported in this configuration, which is best suited for scenarios requiring maximum acceleration and efficiency, especially in high-latency networks like satellite links. This deployment type ensures optimized performance and full use of Riverbed acceleration capabilities.

A single-ended interception (SEI) connection involves one SteelHead paired with a third-party device running TCP-PEP, which communicates using SCPS to accelerate traffic across high-latency links. The SteelHead can be placed in the data center or branch office. This is called a single-ended connection because only one SteelHead intercepts traffic.

A SteelHead in a single-ended connection deployment:

SEI connections count toward the connection count limit on the SteelHead.

Use single-ended connection rules to determine whether to enable or pass-through SCPS connections.

In SEI configurations where the SteelHead initiates the SCPS connection on the WAN (typically on the client side), we recommend you add an in-path pass-through rule for connections from the client to the server. Although this rule is optional, it can significantly speed up the connection setup process. Without it, the SteelHead attempts to probe for a peer appliance. When no peer is found, the appliance enters a failover state, which delays optimization. By explicitly allowing the traffic to pass through, the SteelHead bypasses the need for autodiscovery and failover, resulting in a faster and more efficient setup.

In contrast, for SEI configurations where the SteelHead terminates the SCPS connection (typically on the server side), an in-path pass-through rule is not required. This is because, in such deployments, the SteelHead evaluates only the single-ended connection rules table and ignores the in-path rules altogether. This simplifies the configuration and reduces unnecessary rule management on the terminating side.

When server-side network asymmetry occurs in SEI configurations, the behavior of the SteelHead differs from that of non-SCPS deployments. In SEI, the server-side SteelHead detects the asymmetry and logs a "bad RST" entry in its asymmetric routing table. This is unlike standard configurations, where the client-side SteelHead usually detects the asymmetry. The key distinction here is that in SEI deployments, each SteelHead independently detects and logs asymmetric conditions without relying on communication with other SteelHeads. As a result, if autodiscovery is disabled, the system defaults to a TCP proxy-only connection between the client-side SteelHead and the server, rather than attempting further optimization across an asymmetric WAN path.