Packet Mode Optimization
  
Packet Mode Optimization
This chapter describes packet mode optimization. Packet mode optimization enables the SteelHead to perform packet-by-packet traffic optimization on various types of IPv4 and IPv6 traffic. This chapter includes the following sections:
•  Overview of Packet Mode Optimization
•  Comparison with TCP Proxy Mode Optimization
•  Configuring Packet Mode Optimization
•  Design Considerations
•  Best Practices for Packet Mode Optimization
This chapter requires that you be familiar with Optimization Techniques and Design Fundamentals, including data streamlining and fixed-target in-path rules.
For more information about IPv6, see IPv6.
Overview of Packet Mode Optimization
In RiOS 7.0 or later, the packet mode optimization feature can optimize TCP IPv6 and UDP IPv4 traffic. When you use packet mode optimization, the SteelHead applies the same SDR and LZ data streamlining techniques to UDP or TCP IPv6 packets. Packet mode optimization achieves data reduction rates similar to TCP IPv4 traffic.
RiOS 8.5 or later expands support of packet mode optimization to include TCP IPv4 and UDP IPv6 traffic. In addition, connection or flow reporting for packet mode optimization is greatly enhanced. To optimize TCP IPv4 or UDP IPv6, the client-side and server-side SteelHeads must run RiOS 8.5.
Comparison with TCP Proxy Mode Optimization
The bulk of most network traffic is TCP IPv4 traffic, which SteelHeads typically optimize using a TCP proxy architecture. TCP proxy mode optimization separates a TCP connection into three individual connections:
•  Client to client-side SteelHead
•  SteelHead to SteelHead
•  Server-side SteelHead to server
The advantage of TCP proxy mode is that it increases performance. Because the SteelHead acts as a local proxy to the host, the SteelHead is able perform transport streamlining and application streamlining, which results in increased user performance.
However, 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 in which the SteelHead looks at a packet, or small group of packets, and performs SDR and LZ on the data payload for data reduction. The host and SteelHead do not 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 does not proxy or perform intelligent application prediction.
Packet mode optimization is unidirectional—from sender to receiver—which is an effect of not acting as a proxy. For example, take two sites with SteelHeads, Site A and Site B. A device at Site A sends SNMP traps over UDP to a server at Site B, and only SteelHead A is configured to optimize UDP traffic to SteelHead B. If the server at Site B, for some reason, responds over UDP to the device at Site A, this traffic is not optimized unless you have configured SteelHead B to optimize UDP traffic to SteelHead A.
Configuring Packet Mode Optimization
This section describes how to configure packet mode optimization for UDP IPv4 and TCP IPv6 traffic.
Packet mode optimization supports only correct addressing. Packet mode optimization does not support autodiscovery and requires that you configure fixed-target, packet-mode, in-path rules.
For more design details, see Design Considerations.
Note: The following example shows UDP traffic.
To configure packet mode optimization for IPv4 traffic
1. From the Management Console, choose Optimization > Network Services: General Service Settings and select Enable Packet Mode Optimization; otherwise, use the packet-mode enable command.
2. Configure a fixed-target (packet mode optimization) in-path rule on the initiating SteelHead.
To optimize traffic in both directions, you must configure a similar in-path rule on the peer SteelHead.
Figure: Fixed-Target (Packet Mode Optimization) Rule for UDP IPv4 Traffic shows an example that creates an in-path rule with the following key settings.
Field
Option
Description
Type
Fixed Target (Packet Mode Optimization)
Specifies the rule type for performing packet mode optimization.
Source Subnet
All-IPv4
Selects all IPv4 addresses. You can choose specific IP addresses or ranges.
Destination Subnet
All-IPv4
Selects all IPv4 addresses. You can choose specific IP addresses or ranges.
Protocol
UDP
Selects optimization of TCP, UDP, or any type of traffic.
Target Appliance IP Address
10.32.9.211
Specifies the remote SteelHead to optimize to. You must specify a target with a fixed-target rule. You can also specify a backup appliance. A backup SteelHead is not specified in this example.
Data Reduction Policy
Normal
Specifies SDR, LZ, or both for data reduction. Normal usage includes both.
Position
End
Determines which position the rule is in the rule list. You can decide this based on your environment.
 
Figure: Fixed-Target (Packet Mode Optimization) Rule for UDP IPv4 Traffic
3. Click Add.
To optimize IPv6 traffic, you must enable packet mode optimization and create a fixed-target packet-mode rule similar to IPv4 traffic, but you must enable IPv6 (IPv6 is enabled by default) and configure an IPv6 setting on the SteelHead in-path interfaces.
Note: This example shows TCP traffic.
To configure packet mode optimization for IPv6 traffic
1. From the Management Console, choose Optimization > Network Services: General Service Settings, otherwise use the packet-mode enable command.
2. Configure a fixed-target (packet mode optimization) in-path rule on the initiating SteelHead.
To optimize TCP traffic in both directions, you must configure a similar in-path rule on the peer SteelHead.
Figure: Fixed-Target (Packet Mode Optimization) Rule for TCP IPv6 Traffic shows an example that creates a rule with the following key settings.
Field
Option
Description
Type
Fixed-target (packet mode optimization)
Specifies the rule type for performing packet mode optimization.
Source Subnet
All-IPv6
Selects all IPv6 addresses. You can choose specific IP addresses or ranges.
Destination Subnet
All-IPv6
Selects all IPv6 addresses. You can choose specific IP addresses or ranges.
Protocol
TCP
Selects optimization of TCP, UDP, or any type of traffic.
Target Appliance IP Address
10.32.9.211
Specifies the remote SteelHead to optimize to. You must specify a target with a fixed-target rule. You can also specify a backup appliance. A backup SteelHead is not specified in this example.
Data Reduction Policy
Normal
Specifies SDR, LZ, or both for data reduction. Normal usage includes both.
Position
End
Determines which position the rule is in the rule list. You can decide this based on your environment.
 
Figure: Fixed-Target (Packet Mode Optimization) Rule for TCP IPv6 Traffic
3. Click Add.
4. Connect to the Riverbed CLI. You can also use the SteelHead Management Console.
5. Enable IPv6.
IPv6 is enabled by default, unless you are using a RiOS version earlier than 8.0.
6. Configure an IPv6 address on a SteelHead in-path interface: interface inpathX_Y ipv6 address <address> <mask-length>.
7. Add IPv6 routes: ipv6 in-path route inpathX_Y <prefix> <prefix-length> <nexthop-v6-address>.
For example, ipv6 in-path route inpath0_0 0::0/0 ba5e:ba11:bab3:f005:ba11:bab3:dead:bea7 sets a default IPv6 gateway.
Design Considerations
Packet mode optimization does not support several network integration features available with TCP proxy optimization. The following limitations apply to packet-mode optimized traffic.
Packet mode optimization in RiOS 8.5 or later supports:
•  only fixed-target (packet mode optimization). autodiscovery is not supported.
•  only correct addressing. Full transparency and port transparency are not supported. Because full transparency is not supported, VLAN transparency is also not supported.
•  physically and virtually in-path deployments. The exception is WCCP for IPv6 traffic, because the SteelHead WCCPv2 implementation currently does not support IPv6.
•  data reduction for all IPv4 and IPv6 traffic.
•  connection reporting of packet-mode optimized traffic flows.
Packet mode optimization does not support:
•  RSP data flow rules.
•  NetFlow export of the packet-mode optimized traffic.
•  connection forwarding. This limitation does not imply that parallel SteelHead deployments do not work. As each flow is optimized unidirectionally, asymmetry does not have the same relevance on packet-mode optimized traffic.
•  SteelHead Interceptor deployments.
•  server-side out-of-path configuration.
•  QoS shaping, enforcement, or marking. All packet-mode optimized traffic matches the default QoS default rule and class. The exception is UDP IPv4 traffic, which you can place into an MX-TCP class.
For more information about MX-TCP class, see MX-TCP.
Best Practices for Packet Mode Optimization
Riverbed recommends that you use the following best practice guidelines when using packet mode optimization:
•  Target specific applications and servers for packet mode optimization - Similar to the considerations when performing optimization on TCP IPv4 traffic, certain traffic types do not lend themselves well to data reduction. For example, encrypted or compressed traffic does not receive significant data reduction. Riverbed recommends that you use rules targeting specific networks or ports instead of using broad All-IP targets. Traffic types such as TFTP or UDP-based replication traffic are example target applications.
•  Do not optimize voice or video bearer traffic - While VoIP is one of the more pervasive applications over UDP, VoIP and video RTP traffic are already compressed using specialized codecs. If you attempt to perform further data reduction with SDR or LZ, it is ineffective and can add latency resulting in jitter.
•  Use TCP proxy mode optimization - For application latency improvements for TCP IPv4 or IPv6 traffic, you can use the typical TCP proxy mode optimization. RiOS 8.5 or later includes TCP proxy mode optimization for IPv6 traffic.
For information about IPv6 traffic, see IPv6.