Copyright © 2007 Juniper Networks, Inc. Proprietary and Confidentialwww.juniper.net 1 What can happen when you accelerate a flow twice?

Copyright © 2007 Juniper Networks, Inc. Proprietary and Confidentialwww.juniper.net 2 Situation: Strict Traffic Policy Network In this network due to policies in place all traffic traverses the HQ office even if traffic is destined between spokes where network connectivity may exist. Reasons for this vary, but often it is due to centralized traffic monitoring, firewalls, IDP, etc.. Even with these policies in place TCP/Network sessions still exist between just two endpoints.

Copyright © 2007 Juniper Networks, Inc. Proprietary and Confidentialwww.juniper.net 3 WAN optimization approaches that won’t work in some centralized filtering/monitoring environments Forming tunnels or optimized connections directly between spoke devices. This will obscure the traffic from the firewall. By using the src/dst IP of the WAN optimizers and encapsulating traffic in UDP or TCP the firewall cannot do deep packet inspection. IP transparency Some solutions may provide limited transparency of traffic src/dest IP and port numbers are preserved. Still the data is unreadable because of compression so the firewall still cannot do deep packet inspection 1 2

Copyright © 2007 Juniper Networks, Inc. Proprietary and Confidentialwww.juniper.net 4 Typical traffic flow for optimized WAN Typical WAN optimization techniques tunnel traffic between WAN optimization devices. This allows for TCP/Protocol acceleration to be applied and traffic can be highly compressed. Greatly improving performance of applications over the WAN. In order to perform TCP acceleration the single TCP session that went between the two endpoints is now divided into three separate TCP sessions. 1)Between local client and WAN optimizer 2)Between WAN optimizers 3)Between remote client and WAN optimizer Since WAN optimization devices are designed to manage TCP sessions in this way optimum performance is achieved

Copyright © 2007 Juniper Networks, Inc. Proprietary and Confidentialwww.juniper.net 5 Optimized TCP connection between HQ and Spoke WAN optimizers rely on tight communication of information between each other that constantly monitor the link conditions like delay, loss, jitter, etc… This enables WAN optimizers to reliably manage the locally terminated TCP connections and achieve the best performance for applications in a wide variety of conditions. Additionally many advanced features like application specific acceleration, CIFS, QoS, etc… rely on having a contained point to point TCP connection. So in this network communication between the HQ site and the spokes works as expected 1 2 3

Copyright © 2007 Juniper Networks, Inc. Proprietary and Confidentialwww.juniper.net 6 TCP connection between spokes When TCP connections get formed between spokes in this environment six TCP sessions are created. Now two pairs of WAN optimizers are managing the traffic flow independently of each other. Each link will have different properties, speed, loss, latency, congestion, etc… but in this case there is no complete picture between WAN optimizers. This can result in sub-optimal performance that will be difficult to troubleshoot. Advanced WAN optimization services like QoS will be difficult or impossible to manage reliably, because there is no end to end control over the traffic

Copyright © 2007 Juniper Networks, Inc. Proprietary and Confidentialwww.juniper.net 7 Application acceleration between spokes All application acceleration technologies do things like request additional data from applications, locally acknowledge requests and respond locally on behalf of the servers for some client requests. These types of operations are well understood and safe when the WAN optimization devices sit locally at each end of the connection. However, in cases like this one when that end to end communication appears to be there, but in reality is not. Various problems or performance issues can occur

Copyright © 2007 Juniper Networks, Inc. Proprietary and Confidentialwww.juniper.net 8 Application acceleration between spokes, data pre-fetching example In this simplified example we can see that the chaining of pre-fetch requests could cause issues in how applications will perform. Each pair of optimization devices make separate decisions on what the appropriate amount of data is to pre-fetch based on the link characteristics. The first pair determined that 1Mb of data was the optimal amount of data to pre- fetch. The second pair determined that 2Mb needed to be pre-fetched beyond the last read request so a total of 3Mb is read from the server. This can cause buffers to be filled unnecessarily resulting in some traffic not being optimized or throttled back. It may take too long to empty the buffers because too much data was requested which can cause applications to reset, hang or perform poorly. Excessive pre- fetching may also overwhelm the server with requests Client requests 64K bytes of data WAN optimizers request 1Mb of data based on WAN link WAN optimizers request additional 2Mb of data based on WAN link Server gets request for 3Mb of data Data Pre-fetching is where WAN optimization devices read ahead in the file request beyond what the real client does. By staying ahead of the client they can then service the clients next requests locally from memory or disk.

Copyright © 2007 Juniper Networks, Inc. Proprietary and Confidentialwww.juniper.net 9 Things to keep in mind in Policy Routed Networks where flows could be accelerated multiple times  Application acceleration should only happen on one pair of devices  Chaining of application requests can cause minor to severe problems  Careful planning should be done when optimizing traffic in policy routed environments  While this may work fine in a lab environment careful planning and monitoring during rollout should be done when deploying such a solution. This is not a current large scale QA test case  For best stability and performance flows should only be accelerated once.  TCP acceleration is simpler and is more tolerant of double acceleration, but may still have issues. This is also not a current large scale QA test case

Copyright © 2007 Juniper Networks, Inc. Proprietary and Confidentialwww.juniper.net 10 Alternatives  Allow tunnels to be formed directly between locations that will be optimized.  Optimize only the locations that have the biggest pain points and can still conform with the network policies  For locations that will see large benefits, but cannot be optimized in the current network policy Consider making exceptions if only one or two cases Distribute firewalls, monitoring, IDP to the edges of the network for some locations.

Copyright © 2007 Juniper Networks, Inc. Proprietary and Confidentialwww.juniper.net 11 Copyright © 2007 Juniper Networks, Inc. Proprietary and Confidentialwww.juniper.net 11