About SCPS connections
You can deploy appliances in either double-ended or single-ended topologies. A double-ended SCPS connection is established between two appliances, each of which must be SCPS compatible. Double-ended connections benefit from traditional optimization (SDR and LZ), and all licensed product features are supported with this type of deployment.
SCPS double-ended connection
A single-ended interception (SEI) connection is established between a single SteelHead paired with a third-party device running TCP-PEP (Performance Enhancing Proxy). The SteelHead and the TCP-PEP device use the SCPS protocol to speed up data transfers on satellite, or other high-latency, links. In the following figure, the SteelHead replaces a third-party device running TCP-PEP in the data center, but the SteelHead can also reside in a branch office. Because there’s only one SteelHead that intercepts the connection, this is called a single-ended connection.
SCPS single-ended connection
A SteelHead in a single-ended connection deployment:
• accelerates only sender-side TCP.
• supports virtual in-path deployment such as WCCP and PBR.
• can’t initiate SCPS connections on server-side, out-of-path appliances.
• supports kickoff.
• supports autodiscovery failover (IPv6 supported).
• supports high-speed TCP.
• doesn’t support connection forwarding.
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.
We recommend that for SEI configurations in which the SteelHead initiates the SCPS connection on the WAN, you add an in-path rule that passes through connections from the client to the server. While the pass-through rule is optional, without it the SteelHead probes for a peer appliance, and when it doesn’t locate one, will failover. Adding the in-path pass-through rule speeds up setup by eliminating the autodiscovery probe and subsequent failover. An in-path pass-through rule isn’t necessary on SEI configurations where the SteelHead terminates the SCPS connection, because it evaluates only the single-ended connection rules table and ignores the in-path rules table.
When server-side network asymmetry occurs in an SEI configuration, the server-side SteelHead creates a bad RST log entry in the asymmetric routing table. This log entry differs from other configurations (non-SCPS) in that the client-side SteelHead typically detects asymmetry because of the bad RST and creates an entry in the asymmetric routing table. In SEI configurations, the SteelHead detects asymmetry and creates asymmetric routing table entries independent of other SteelHeads. This results in a TCP proxy only connection between the client-side SteelHead and the server when autodiscovery is disabled.