Seeing through transparency claims

WAN acceleration and optimization techniques require communication between devices for consistent, reliable compression and decompression of data packets. In this tip, learn the pros and cons of header transparency and peering technologies and find out various methods acceleration vendors use to provide end-to-end visibility across the WAN.

Many Wide Area Network (WAN) acceleration solutions are "symmetric" in nature, requiring communication between devices on each end of a WAN link. In order for these solutions to work, there must be a reliable way for traffic to be encoded/compressed on one end of the WAN link and successfully directed to a device on the other end of the link, where the traffic can be decoded/decompressed before final delivery.

There are two primary ways in which symmetric acceleration devices communicate across a WAN. These are:

  1. Header transparency: WAN acceleration appliances preserve the original source and destination IP addresses of the clients and servers when sending packets across the WAN. This information is used to route accelerated traffic across the WAN in the same manner as un-accelerated traffic. It is important to point out that while the headers remain unchanged in this scenario, payload information is fundamentally altered as compression, data reduction and other acceleration techniques are applied to the WAN traffic.
  2. Peering: During transit over the WAN, the original source IP address is replaced with the IP address of the near-end WAN acceleration appliance. The original destination IP address is replaced with the IP address of the far-end acceleration device. Peering is most commonly implemented using Network Address Translation (NAT) or by encapsulation within tunneling protocols, such as GRE.

    By using intermediary IP addresses, peering establishes well-defined ingress and egress points for all accelerated traffic across the WAN. After acceleration takes place, the intermediary headers are replaced with the originals. As is the case with header transparency, when traffic is optimized and sent across the WAN using peering, payload information is inherently altered.

Technology comparison

There are advantages and disadvantages to the different methods of communication across a WAN. Header transparency improves visibility into the header, which can be used to enforce downstream ACLs and QoS policies on simple protocols, such as CIFS. It does not provide visibility into the payload, however, and this limits its value when applications use ephemeral ports (e.g., VoIP, FTP and MAPI). In addition, this method can actually be problematic when downstream devices are using deep-packet inspection to compare header information with payload information, and can be costly to deploy and complicated to manage in networks with multiple WAN paths.

More on this topic
WAN acceleration scalability

WAN optimization crash course

More tips on Wide Area Networks

More tips on Network Management
With peering, on the other hand, optimized traffic can be distinguished from non-optimized traffic across the WAN. Peering is also less disruptive to IDS/IPS, firewalls and other downstream devices that map headers to payload information. Peering is more robust and reliable because optimized traffic is explicitly directed to the peer, where it is converted back into normal traffic before being forwarded to the end user. However, it does not natively provide visibility into the header, which can sometimes be used to preserve existing policies (i.e., when applications use static ports). This visibility must be provided using additional techniques.

A clear vision for transparency

Both methods described above are effective ways of communicating across a WAN, but neither method -- by itself -- delivers the level of transparency required to preserve all existing policies across a WAN. Any claims to the contrary are deliberately misleading. For a WAN acceleration solution to be truly transparent it must:

  • Work across all applications, not just those using a specific type of port or transport protocol.
  • Co-exist with other devices in the network, such as IDS/IPS and firewalls.
  • Be completely seamless to the client, server and application itself without any risk of data corruption.

To achieve end-to-end transparency, vendors have to augment one of the above communication methods with other techniques. For example, the following can be used in conjunction with peering to provide end-to-end visibility across the WAN:

  • Deep-packet inspection delivers detailed visibility into all traffic, including those applications that use ephemeral ports. Best practice indicates that deep inspection and related functions take place prior to WAN optimization or within the optimization appliance itself. Otherwise, WAN optimization techniques that obscure payload information may render devices that use deep-packet inspection useless.
  • "Auto-optimization" enables the first few packets in a flow to be sent across the WAN in the clear so that existing policies can be enforced appropriately prior to optimization. For example, if an ACL exists within the WAN to deny a specific type of traffic, acceleration appliances will not optimize this traffic and the ACL will continue to function as if the appliance were not there. This process is similar to the one used by Layer 3 switches, whereby for each new flow, the first few packets are processed by an embedded router and then copied for the remaining packets (hardware fast path).
  • DSCP tags can be used to preserve QoS policies within the WAN acceleration appliance. These devices can also overwrite DSCP tags based on configurable QoS policies.
  • Netflow is often used to collect network-flow-based statistics and traffic accounting information on all traffic, which can be exported to external devices in a well-defined format that is easily recognized. This enables a variety of key tasks, such as network traffic accounting, usage-based network billing, network planning, security, Denial of Service (DoS) protection, and network monitoring.

About the author:
Dr. David Hughes founded Silver Peak Systems in 2004 and previously held senior architect positions with Cisco Systems, Stratacom, Blueleaf and Nortel. He has a PhD in packet network optimization.

This was first published in January 2007

Dig deeper on Network Performance Management

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSDN

SearchEnterpriseWAN

SearchUnifiedCommunications

SearchMobileComputing

SearchDataCenter

SearchITChannel

Close