WAN optimisation reinvented with Cisco WAAS, NetQoS

SearchNetworking ANZ recently spoke with NetQoS sales engineer Lindi Horton, who was the technical lead on the Cisco WAAS-NetQoS integration code.

At last month's Cisco Networkers conference, Cisco and NetQoS announced plans to integrate monitoring capabilities into Cisco WAAS WAN optimisation tools. The goal, both vendors said, is to show just how applications are responding over the WAN and provide accurate response times, making the stopwatch approach a thing of the past.

SearchNetworking ANZ recently spoke with NetQoS sales engineer Lindi Horton, who was the technical lead on the Cisco WAAS-NetQoS integration code. Horton said enterprises crave visibility into how applications are truly performing over the WAN, but there is still a learning curve as companies grapple with how to extend the network and applications into branch offices.

What was the genesis of the NetQoS and Cisco Wide Area Application Services (WAAS) integration to give this visibility into how things are being optimised?

Lindi Horton: What really happened was some of our executives sat down with some of the Cisco executives at a conference back in November. We had identified that through WAN optimisation, all of the current performance monitoring capabilities are broken. Even the capabilities we have as far as the passive solution from the data centre's perspective, as well as any sort of active agents, are completely broken when you introduce WAN optimisation into the environment due to the localised acknowledgement and caching technologies.

We needed to identify a resource or a partner and develop a solution around WAN optimisation. Cisco at the time was also searching for a way to help with understanding the performance impact and helping to quantify that impact when they actually say, "Hey, my ROI for optimisation is 80%; how am I going to be able to prove to the customer that is what's happening?" At the time, they were just using a stopwatch and transferring a file over. They were looking for a better solution that would help them get visibility into what was happening inside the WAN optimisation devices.

Why isn't the stopwatch approach adequate?

Horton: It's not inadequate, but on an ongoing basis, when you're looking at improving WAN optimisation and improving the end-user experience, there are a lot of variables that change over time. In a production network, the initial ROI can probably be quantified there, but then you actually have a spreadsheet to give to upper management. They wanted some pretty graphs."¦ As far as an ongoing basis and maintenance, there are other applications and changes that occur in the environment, and they want to know if the other applications that are rolled out impact the WAN-optimised applications. They want something that will trend over time.

With the NetQoS-Cisco integration, what are the folks in the trenches who keep tabs on the WAN really getting?

Horton: What they're really getting is the ability to understand from an end-user response time perspective how much the application is improving by adding WAN optimisation.

Why is that important?

Horton: The reason they're using WAN optimisation technology is to improve end-user experience with those applications. A lot of risk gets associated with saying, "OK, we're going to deploy these things, but we don't know if they're really going to do what they said they're going to do."

What are some of the other misconceptions enterprises have when it comes to optimising applications over the WAN?

Horton: A lot of them just don't have any visibility into what their traffic flow is to the branch [office]. So they don't even know what kind of applications the branch offices are using and how that traffic is flowing into the data centres. A lot of times, they are hoping to throw a solution at something that may or may not really improve the performance of applications. If they're highly UDP-based applications, there are very few things they can do to improve the overall performance.

The first thing they want to do is gain visibility into what the users are actually using, which changes day to day, and do an application profile of what's flowing across those links and what applications are being optimised. And then take the perspective of, "If we do deploy WAN optimisation, does that actually improve the applications that we wanted to improve? We want to improve the business-critical applications, like SAP and CRM. But if it's all Internet traffic, we don't really care if that's saturating the network, we just want to reduce that and focus on those business-critical applications."

Once these companies have visibility at their fingertips, beyond printing out pretty reports for ROI purposes and to show someone in the corner office, what other benefits do they get?

Horton: It's just the fact that in very large enterprise environments, it's all about a bunch of moving parts. There are changes that occur every day, and usually what happens with those is getting that visibility into troubleshooting if a change actually affected the performance of applications. By having the end-to-end response time statistics, over time I can compare what the environment was like yesterday to what we're seeing today and say, "OK, something in the network has changed; is it network, server or application latency that's changed?" Then I can go and drill into the changes that occurred that might have introduced that problem.

What do companies do now to troubleshoot without that visibility? Are they taking shots in the dark to find what's causing a problem?

Horton: It's very hard for them to quantify and resolve in a timely manner. One of the goals our customers come to us with is reducing the mean time to repair a problem. Currently, there are some great technologies out there that let you do packet captures and packet analysis, but on an ad hoc basis. They would go deploy a sniffer, get a packet trace and try to find the anomaly inside the packet trace. But if they don't have a baseline to compare that to, it makes it much more difficult for them to say, "Oh, this is the red circle; this is the area I need to focus on."

What are some of the applications whose performance levels companies are most interested in keeping tabs on?

Horton: There are about 10 major applications that companies ask us to be able to quantify. Most enterprises have developed their own internal customer applications. Those are typically the first ones because they're developed by in-house application developers who may not understand WAN deployment scenarios. Email has become a huge business-critical application, and they really want to understand how much email traffic they have. Even though it's voice, Voice over IP is another application that -- converged onto a data network -- presents some risks that they want to be able to mitigate. SAP, PeopleSoft, Oracle-based applications -- those are all very common in the enterprise environment and things they really want to understand. And many of the Citrix clients: How do I understand what Citrix is doing? Anything that they deliver through the Citrix applications is something they want to look at.

Why partner with Cisco and its WAAS solution instead of going with one of the host of other WAN optimisation vendors?

Horton: It's more about being able to understand if you've actually improved the end-user experience. The NetQoS-Cisco partnership is the only partnership on the market that's actually going to give accurate response time statistics to a WAN-optimised deployment. NetQoS supports NetFlow, and we've done other customer support with NetFlow technologies from other WAN optimisation vendors, but if they're really looking to improve the end-user response time and be able to quantify that, they're going to have to go with the Cisco WAAS-NetQoS solution.

Where do you see this going in the future as enterprises continue to add more and more applications onto the network? What are companies going to demand going forward?

Horton: Going forward, they're going to continue to demand more visibility into the rest of their infrastructure as to what end users are actually using on the network. We already have some information about capacity planning and bandwidth usage plans where they're learning to look at the performance of the network. We're seeing a lot of data centre consolidation and convergence. Companies want to be able to consolidate any of the applications that may have been distributed out to the branches back into the data centre.

We're also going to see a lot more consolidation and virtualisation efforts coming in the next five years or so.

Do you think that companies have an unrealistic goal in mind when they consider WAN optimisation? Do the success stories out there of speedier applications put stars in their eyes?

Horton: I think they probably do. That's what we're seeing in some of the lab environments that we're doing right now. Setting the expectation of the customer is part of the engineer's goal. It really depends on the application as to what they're really going to get for performance. Certain applications optimise really well; others do not. I think we're going to see a lot more education on the part of both the customer and all of the vendors in this space.

Why is that education important moving forward?

Horton: It's not just for WAN optimisation. In today's world, in the networking world, we have to understand how the application performs over a network, especially over different media, such as wireless, MPLS and different types of networks. Network engineers and network managers need to understand how those applications work to be able to make those decisions. They have to move into an application-specific space to design QoS policies and the correct mechanisms around each application. This has already started, and I think WAN optimisation has been a big impetus to move that forward.

How do WAN optimisation capabilities and the proliferation of branch offices, data centre consolidation and all of that change the roles of the "WAN guy" and the "network guy"?

Horton: We've already seen a lot of this started, even from learning about MPLS and how it works. You see a lot of the network guys converging into other silos, into server and application spaces just to understand how to deliver those applications over the network. From the WAN guy's perspective, his day-to-day responsibilities now include VPNs, MPLS, all of these other different technologies that he didn't have five years ago. You see just a big education on his part to understand not just point-to-point routes, but now he has five different ways he has to deliver these applications, and when they break, he has to troubleshoot that. It's quite a hefty learning curve.

What other advice would you offer to our readers?

Horton: I think the biggest thing is to emphasise the importance of having visibility into the network. That's usually done through a number of different mechanisms, not only through response times, but NetFlow, SNMP, IP SLA type technologies to get the engineers as much information as possible about what's really going on over time in order to help them make decisions about whether they should use WAN optimisation and whether it's a server, network or application problem. I think that


Read more on WAN performance and optimisation