In-path rules are used only when a connection is initiated. Because connections are usually initiated by clients, in-path rules are configured for the initiating, or client-side, SteelHead. In-path rules determine SteelHead behavior with SYN packets.

In-path rules are an ordered list of fields a SteelHead uses to match with SYN packet fields (for example, source or destination subnet, IP address, VLAN, or TCP port). Each in-path rule has an action field. When a SteelHead finds a matching in-path rule for a SYN packet, the SteelHead treats the packet according to the action specified in the in-path rule.

In-path rules are used only in these scenarios:

Both of these scenarios are associated with the first, or initiating, SYN packet of the connection. Because most connections are initiated by the client, you configure your in-path rules on the client-side SteelHead. In-path rules have no effect on connections that are already established, regardless of whether the connections are being optimized.

In-path rule configurations differ depending on the action. For example, both the fixed-target and the autodiscovery actions allow you to choose what type of optimization is applied, what type of data reduction is used, what type of latency optimization is applied, and so on.

RiOS 7.0 and later include fixed-target, packet-mode optimization in-path rules. The SteelHead treats the packets for packet-mode optimization rules differently from the in-path rules described in this overview. For details, see Creating In-Path Rules for Packet-Mode Optimization.

RiOS 8.5 and later expand packet-mode optimization to include TCPv4 and UDPv6 traffic. In addition, RiOS 8.5.x and later enhance connection or flow reporting for packet-mode optimization. To optimize TCPv4 or UDPv6, the client-side and server-side SteelHeads must run RiOS 8.5 or later.

For details on IPv6 deployment options, see the SteelHead Deployment Guide.

You can configure optional settings to support a variety of deployment needs, including:

RiOS performs packet-by-packet scalable data referencing (SDR) bandwidth optimization on TCP and UDP flows over both IPv4 and IPv6, using fixed-target, packet-mode optimization in-path rules. This type of in-path rule optimizes bandwidth for applications over any transport protocol.

Sometimes you might want to use the SteelHead optimization to reduce the amount of traffic traversing the WAN. Packet-mode optimization provides a simple approach where the SteelHead looks at a packet, or small group of packets, and performs SDR and LZ compression on the data payload for data reduction. The host and SteelHead don’t create an individual TCP handshake, and the SteelHead reduces payload for packets as the traffic flows through.

The advantage of packet-mode optimization is that it is a universal method that applies data streamlining to diverse protocols. The disadvantage is the lack of performance benefits from transport streamlining or application streamlining, because the SteelHead doesn’t proxy or perform intelligent application prediction.

In RiOS 8.5 or later, consider using the typical terminated TCP optimization to improve application latency instead of packet-mode for TCPv4 or TCPv6 traffic. RiOS 8.5 and later include TCP proxy-mode optimization for IPv6 traffic. To use terminated TCP optimization after upgrading from RiOS 8.0.x to 8.5 or later, you must change any existing in-path rule used for packet-mode IPv4 or IPv6 optimization to a terminated optimization rule.

Upgrading from RiOS 8.0.x (or earlier) to 8.5 or later might require a configuration modification to deployments optimizing only the server-to-client direction of a TCPv6 connection using packet-mode.

Consider a deployment running RiOS 8.0 with packet-mode optimization enabled on the client-side and server-side SteelHead. The server-side SteelHead is configured with server-to-client fixed-target packet-mode rules. As a result, any traffic flowing from the server to the client for connections that originated at the client receive packet-mode optimization.

The packet-mode rules exist only on the server-side SteelHead. No other rules are configured on the client-side or server-side SteelHeads.

Because the client-side SteelHead doesn’t have fixed-target rules matching the client to server traffic, it passes it through according to the default TCPv6 rule.

After upgrading the client-side and server-side SteelHeads to RiOS 8.5 in this deployment scenario, connections originating from the client toward the server now receive terminated TCP optimization. This happens because RiOS 8.5 and later support terminated optimization for TCPv6 and the connections originating from the client now match the default optimization (terminated-mode) rule on the client-side SteelHead. As a result, the server-to-client traffic of these connections also receives terminated TCP optimization.

To continue passing through the client-to-server traffic and optimizing the server-to-client traffic using packet-mode, as before the upgrade, you need to configure a pass-through in-path rule on the client-side SteelHead.

When you create a fixed-target packet-mode optimization rule, you define the inner channel characteristics using these controls: source and destination subnet, source and destination port (or port label), and DSCP marking.

Packet-mode optimization supports these topologies:

Packet-mode optimization doesn’t support these topologies:

For details, see Configuring In-Path Rules. For design considerations and best practices, see the SteelHead Deployment Guide.

Three types of default in-path rules ship with SteelHeads. These default rules pass through certain types of traffic unoptimized. The primary reason that these types of traffic are passed through is because you are likely to use these types of protocols (telnet, SSH, HTTPS) when you deploy and configure your SteelHeads. The default rules allow the following traffic to pass through the SteelHead without attempting optimization:

We recommend you retain the default rules. However, you can remove or overwrite the default in-path rules by altering or adding other rules to the in-path rule list, or by changing the port groups that are used.

For details about changing port labels, see Configuring Port Labels.