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 Lempel-Ziv (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.

A fixed-target packet-mode optimization rule creates an inner TCPv4 or TCPv6 channel between the SteelHeads. See Figure 4-1.

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.