Part 5 in a series adapted from Joel Trammell’s Keynote Speech at NetQoS Symposium 2008

One of the big downsides to WAN Optimization is that you’re breaking up the TCP session that used to be from one end of the network to the other into three independent TCP sessions.

To measure the response time after WAN optimization is deployed, NetQoS worked with Cisco to develop code that exists on every Cisco WAN optimization device that ships. That solved the problem – at least for Cisco WAAS users.

But if I can generalize, you talk to a WAN optimization vendor and they will tell you, "Well, who cares about breaking up the TCP session because we're going to make your network so good you're not going to have to deal with performance problems."

That’s not reality. They will solve a certain set of performance problems, to be sure, but in some cases they may exacerbate problems.

For example, earlier this year, I recall that a Riverbed box had serious issues around AutoCAD. When AutoCAD changed the file format version, the WAN optimization implementation was actually slowing down AutoCAD. That’s an important area that people don't necessarily think about when they deploy WAN optimization: Did it actually do any good and how can you quantify how much good it did?

You have to do some pretty sophisticated analysis to understand what applications are going to benefit from WAN optimization, or any other technology addition for that matter, and which aren't. It's not always obvious how much data reduction occurred. That's one of the big selling points, right? You're not going to have to transfer all this volume across the network; well can you quantify how much data reduction occurred on the network?

Finally you want to be careful what applications may break when they're optimized. So, with WAN optimization the network performance metrics you’ll want to see are response time and traffic flows. That ability to understand and “re-put together” the three response time segments that were broken by putting in WAN optimization in the first place.

[Ed. Note: 17 November - In our comments section, Bob Gilbert from Riverbed points out that the AutoCAD problem has been addressed with a patch from Autodesk, and that the problem with AutoCAD's .dwg files were not Riverbed exclusive.]

I can’t believe I missed this the first time around.

I was so focused on how the online Olympic video was getting through the last mile, that I completely forgot to ask: How the heck are they getting it from Beijing to the U.S.?

Douglas Gourlay at Cisco has been blogging about how NBC’s been using Cisco’s Wide Area Application Services (WAAS) for WAN optimization, so that NBC’s video editors can use three 155Mbps OC-3 pipes, combined and load-balanced (with, of course, Cisco gear) to get the files directly from Beijing. While I’m not 100% sure on “as if they were stored locally,” holds true, it’s clear that WAAS is capable of some amazing stuff – we know because NetQoS has SuperAgent integration on WAAS devices and ACE load balancers. We track stuff like that all the time.

“This reduces operating costs of housing, air travel, transportation, and food. Avoiding 800 airplane trips also supports NBC’s green initiatives for the Olympic Games.”

It also probably makes the video editors a bit grumpy that they didn’t get to go to Beijing.

What I’m curious about is what will happen after the Olympics. Just as Olympic stadiums still stand – and are used – in every host city, I’m wondering if the infrastructure that NBC has to Beijing to deliver high definition video will remain after the Olympics. As China starts to become a new superpower, more news and information is bound to come from Beijing, after all.

And if this can be done for one series of events in one major city, is it that far off from having video-heavy WANs in every city to cover every major event?

Earlier today, Network World hosted a live chat with Jim Metzler, of Ashton, Metzler, and Associates on implementing WAN acceleration. They’ll have the full transcript up tomorrow on their site, but I attended and wanted to bring back a few highlights. 

-----

Question: What is the one question that should be asked when evaluating products that you don't see people asking?

Jim Metzler: One thing that I think that people should ask: What has gone wrong in previous deployments?  We have all been around long enough to know that things do tend to go wrong at least occasionally.  For example, some people have found that once they deploy a WAN optimization controller (WOC,) that they lose management visibility.

Question: We are constantly battling latency across our MPLS network.  We have retail stores that connect to HQ data center.  How do we improve WAN performance?  Do we need to implement QoS?  Or should we use a different WAN protocol for our Cisco routers?

Jim: MPLS comes along with service classes that promises a guaranteed latency.  For example, a given service class may promise that latency will not exceed 50ms.  If your problem is that you are not getting what you were promised, that is an issue to take up with your vendor, or, based on your contract, to possibly change vendors.  If the issue is that the latency that you are promised is not good enough, I need to know more about what the problem is.  For example, if the issue is that you are running chatty protocols over the WAN, then a WAN optimization appliance might be helpful.

Question:  How do WAN optimization technologies fit into a more VIDO oriented desktop/branch and/or more XML oriented apps?

Jim: The movement to implement virtual desktops is a bit behind the movement to deploy virtual servers.  As we deploy more virtual desktops, that will mean more traffic from the data center to the branch which will most likely need optimization.

Question: How does WAN accellerationfit into scenarios with heavy ICA traffic or Notes replication traffic?

Jim: WAN acceleration is a very broad topic.  Some applications (CIFS traffic that results from server consolidation) scream out for optimization.  Other traffic (VoIP) requires QoS so that other traffic (bulk file transfers do not interfere with it.

The bottom line is that there are differing traffic types and they often require different techniques.

Question: Is there any company that has the best all-around solution?

Jim: No.Okay, my answer was intentionally brief.  Your question goes to one of the key challenges facing IT organizations today.  A given supplier might have a great solution for data replication but not so great for CIFS.  Another vendor may have a great solution for CIFS, but not so much for data replication.

This presents IT organizations with a challenge - what problems are they trying to solve today?  Next year? You have to decide.  Do you choose the best solution to today's problem knowing it might be sub-optimal for tomorrow's?

The good news here is that over time the differences between the suppliers on common functionality (compression, caching, protocol acceleration) will diminish.

Question: What question do you hear the most about this product category?

Jim: “How do I get started with evaluating these products?”  “What new directions are the gear vendors taking these products?”

With regards to WOCs: Adding support for specific applications such as share point or SAP.  Creating templates to make it easier for IT organizations to configure the device to support key applications.  Embracing virtualization.

With regards to Application Delivery Controllers (ADCs): Offering virtualized solutions, adding security functionality, adding functionality such as XML processing, Integrating with Business Intelligence tools. 

Question: Do you see distinct advantages to implementing QoS in a WOC rather than the router level? 

Jim: This is a really fundamental question.  I believe that one of the reasons that we have not implemented WOCs more broadly is that we have not answered some basic questions such as what functionality should be done where.

The question is further blurred by the fact that WOCs are being integrated into routers making it tough to say where QoS was implemented.  Bottom line: I think you can make either approach work.  It comes down to factors such as how rich is the QoS functionality in the WOC and how easy is it to configure and manage the QoS functionality in the WOC or the router.

Question: Some users claim that acceleration claims made by the vendors are bogus, that claims of 400% improvements are marketing garbage (as you can’t improve speed faster than the original base speed) What are your thoughts on speed claims by vendors?

Jim: The acceleration claims made by the vendors represent a test done in a laboratory.  While these might give some insight into how the devices will perform in production networks, they are not definitive.  IT organizations must test the devices in their network to understand what types of improvements they will realize. 

Question: Any thought on masking poor application architectures with WOC or ADC products?

Jim: This is a hot button to me!

For example, most IT organizations do not spend much attention on how apps will perform over the WAN during development or acquisitions.

A lot of our current problems would go away if apps were designed to run better over the WAN.

For example, one company I worked with found out that the browser in the branch offices were downloading a 3MB file just to open it up and extract a 10 digit ID.  Talk about a badly designed application!

Question: Where is the next big thing: security, storage, or--?

Jim: I think that there will be a lot of next big things.  I recently wore a series of articles for Network World in which I described "The Perfect Storm." 

Let me explain.  Today over half of the outages occur based on ineffective change or configuration management.  once we move to an environment with a virtualized desktop, routers running VMs running all kinds of things, communicating with a virtualized application delivery controller (ADC) that front ends a Web server, app server and database server, all of which are virtualized and which use virtualized storage, then the situation gets very thorny. 

Can you imagine how much many more outages will occur in a fully virtualized environment?

Sticking with this: Today when an application is not performing well it is difficult to identify the root cause.  That will be much more difficult in a fully virtualized environment. 

SOA really worries me.  By SOA, I mean Services oriented architecture.  Some think SOA is the precursor to an SOB and they may be right.

With an SOA, an application is comprised of multiple web services - for the sake of example - say 8.  Now, these Web services are running in different data centers - say 5.

Now the WAN impacts that application performance many more times than it does in today's n-tier applications.  This will be a huge challenge, but it gets worse - these Web services are reusable.

That means that multiple apps are using the same web services at the same time - that drives the need for QoS for Web services

This is all extremely demanding. 

Then there is Web 2.0 and mashups. With a Mashup your app is using apps designed and managed by other entities.  You have no control or visibility into those other apps.  This will be extremely challenging.

Last Tuesday, our own Ben Erwin and Michael Leonard, Project Marketing Manager at Cisco, gave a Webinar entitled: “Building Performance-first Application Delivery Networks with Cisco and NetQoS,” where they showed attendees scenario based demonstrations based on a model of “Baseline, Optimize, Control, Quantify, and Troubleshoot,” which is one of the few models in IT that doesn’t have a catchy acronym. I mean, seriously, “BOCQT?” Isn’t that the sound a Ukranian hen makes?

Anyway, Ben Erwin and Michael Leonard have written up answers to all of the questions that they simply weren’t able to get to in the original time allotted. These answers are below:

Q: Our corporate data center has two connections into our MPLS network (for redundancy). How can WAAS be deployed in this scenario?

A: WAAS could be deployed on either or both links. WAAS is aware of asymmetric routing environments, so WAAS can deal with traffic that goes out on one link and returns on the other.

Q: If the NetQoS module or modules require NetFlow, please make a point of mentioning that. We don't have NetFlow, and don't want to buy it unless we have to.

A: The traffic analysis module does require NetFlow (or any flow export data source). If you have Cisco routers and switches in place today, then you already have NetFlow. NetFlow is included in the hardware at no additional cost.

Q: Is ACE optimization available on the ACE modules yet?

A: Yes, you can use ACE to optimize application delivery and baseline, quantify, and troubleshoot with NetQoS.

Q: How do you support new protocols for a new app?

A: NetQoS will automatically detect new protocols on the network. You can then choose to monitor application delivery and the appropriate optimization technology from Cisco.

Q: Can I view my virtual servers with this product?

A: Yes. NetQoS will allow you to monitor traffic to/from virtual servers. WAAS and ACE will also optimize application traffic to/from virtual servers.

Q: Which Cisco platforms must we be on to take advantage of the integration of Cisco and NetQoS?

A: For optimization, Cisco WAAS and ACE. In addition, any router/switch supporting NetFlow, IP SLA, CBQoS, or NBAR will also provide reporting into NetQoS.

Q: What are the instrumentation feeds to NetQoS: WAAS flow agent? NetFlow? What else?

A: SNMP, raw packets, Cisco UC (VoIP) metrics

Q: Does WAAS/ACE work with IPv6 addresses?

A: Not today, but it is under consideration for a future release.

Q: I understand there must be a pair of WAAS for each WAN link, how about ACE, does that need to be a pair also?

A: No. ACE is only deployed in the data center near the server farms.

Q: Do you support any data sources that require a network tap?

A: Nothing requires a network tap. However, a tap can be used to feed NetQoS raw packet data instead of a mirror (SPAN) port.

Q: How well does this technology work with MPLS?

A: All of the technologies mentioned in the presentation can function in MPLS environments. Cisco can optimize traffic over MPLS networks and NetQoS can monitor the delivery of applications over MPLS networks.

Q: Do I need an extra Aggregator for monitoring the WAEs or does a SuperAgent see the statistics of the WAEs ?

A: SuperAgent does require an Aggregator to view traffic from the WAE (WAAS) appliances.

Q: Does NetQoS collect/trend IP SLA data?

A: Yes. NetQoS collects and historically trends IP SLA data.

Q: Are there any detailed documents (engineer level) describing exactly how the integration works between the WAE/WAAS modules and SuperAgent. I need detail to explain exactly why I need it.

A: Yes. If you're a customer or prospect contact your NetQoS account rep. If not, contact the NetQoS sales team at sales@netqos.com and request a technical discussion on the integration.

Q: Is there an agent for the ACE?

A: No. ACE does not require agents.

Q: How does WAAS/ACE work with encryption?

A: Both WAAS and ACE interoperate with SSL encrypted traffic.

Q: We use RDP port 3389 for access to our Server farm. Can we implement NetQoS with this environment?

A: Yes. NetQoS can monitor traffic over RDP ports.

Q: Is this solution well suited for video streaming applications, specifically, real time video feeds?

A: Yes, NetQoS can monitor video traffic's impact on WAN bandwidth, network performance, and application delivery. WAAS has support for Microsoft media based video. WAAS will send only one stream over the core and split stream at the branch to conserve bandwidth.

Q: We are not using Cisco WAAS, but rather a competing product; can you touch upon interoperability with other WAN Acceleration vendors and more on the QoS specific functionality for tuning that?

A: NetQoS can provide traffic statistics if you're product exports flow records. However, these may not be very useful if the optimized traffic is tunneled. You cannot receive accurate response metrics with a non-Cisco optimization product and NetQoS (or any other performance monitoring vendor). Response time monitoring capabilities for optimized environments are only available with the combination of NetQoS and Cisco. Therefore, you would not be able to quantify the impact of any QoS tuning.

Q: Does deploying WAAS include NetQoS SuperAgent functionality, or are they separate products? I heard a rumor that deploying WAAS includes SuperAgent functionality.

A: They are separate products. However, WAAS does include NetQoS code that allows it to interoperate with NetQoS SuperAgent.

Q: How many of Cisco's IP SLA tests does NetQoS currently support? And will NetQoS add support to cover all of Cisco's IP SLA tests?

A: NetQoS supports all of the Cisco IP SLA tests today.

Q: Does WAAS differentiate between MPLS Class of service?

A: Yes, WAAS can give priority and process traffic according to DSCP marking.

Q: If it's not outside the scope of this presentation, can you talk about the performance differences between the inline and non-inline deployment models?

A: Performance is similar in both instances. WAAS implements WCCP as the primary method for non-inline and is tuned to work effectively with the device it is redirecting traffic to so as not to overload it.

Q: Strategically, assuming availability of higher WAN bandwidth at a lower cost, what becomes the core strength of WAAS?

A: WAAS allows you to use your bandwidth more effectively so that you don’t need to overprovision and WAAS overcomes the impact of latency on application performance. Even if you have enough bandwidth in theory, you might not be able to fill the pipe due to the behavior of TCP on links with high latency.

Q: Can you export NAM data to NetQoS today?

A: NetQoS can collect data from NAM’s today via SNMP.

Q: Even custom applications with custom communication formats?

A: Yes. Any custom IP application can interoperate with NetQoS and Cisco.

Q: I take it that this device would allow to see how affective your QOS policy is being. Does this take the place of the QoS Manager?

A: Yes WAAS allows you to see what applications are using your bandwidth and how much bandwidth they are using as well as how much reduction in bandwidth usage WAAS is providing per application. WAAS works with the QoS policies on your router. WAAS can make separate QoS control device unnecessary.

Q: Do I need NetFlow enabled on the remote site and the head office router to do a baseline?

A: NetFlow can be enabled in either location. Baseline calculations are independent of the NetFlow source or location.

Q: The SuperAgent can't tell anything about response times of UDP traffic, but does the SuperAgent show the amount of UDP traffic?

A: Correct, SuperAgent cannot monitor the delivery UDP applications. However, the NetQoS traffic analysis capabilities with Cisco NetFlow can show the amount of UDP traffic on the network. In addition, NetQoS can report Cisco IP SLA metrics to measure UDP latency.

Q: How many (max) ports per NetQoS appliance. Are we talking fiber? Fiber channel?

A: Depending on the capabilities needed, appliances come with 2, 4, or 8 ports with copper, fiber, or fiber channel connectivity.

Q: What hardware is required at a branch office to deploy WAAS?

A: WAAS can be deployed as an appliance or as a network module for the Cisco ISR router.

Q: How do appropriately size the model of WAAS hardware for your network?

A: Cisco provides a sizing tool and sizing guidelines. Sizing is based on throughput requirements and the number of TCP connections to be supported. WAAS was tested by an independent test facility to scale to over 50,000 TCP connections.

Q: How big is the impact on Cisco router processor load, when using NetFlow reporting?

A: 2% or less impact to CPU cycles on any Cisco router/switch model.

Q: Which segment do you use CBQoS statistics and into which metric does it get aggregated?

A: CBQoS data is collected via SNMP with the NetQoS device management capabilities.

Q: Can NetQoS read the real underlying application if another port is used?

A: Yes, NetQoS can provide full deep packet inspection capabilities to read any layer of the application.

Q: How does WAAS work with encrypted MAPI (email) from branch to datacenter?

A: Support for encrypted MAPI is under consideration for a future release. Currently WAAS will not apply full optimizations if the traffic is encrypted but will provide the default L4 optimizations that are effective for Exchange cached mode.

Q: Can WAAS encrypt its optimized traffic?

A: WAAS can encrypt data stored on the disk and WAAS can optimize SSL encrypted traffic. WAAS does not encrypt traffic in flight. WAAS interoperates with your security infrastructure.

Q: Is WAAS and ACE required to measure transactions response time?

A: No. Application delivery and response times can be measured with NetQoS without WAAS or ACE. However, WAAS and ACE are required to optimize the delivery of applications.

By Ben Erwin

Even the WAN optimization vendors are starting to realize that WAN optimization’s utility is diminished without visibility into the network.

Riverbed’s recent announcement shows that they, (and other WAN optimization and acceleration vendors), are recognizing the dependency between better network management and successful WAN optimization projects. The partner vendors mentioned in the announcement all provide some level of network management capabilities, from network configuration to application delivery monitoring. These partnerships are part of a growing trend since network management capabilities are critical to understanding WAN optimization’s ROI and impact on network performance.

In addition to third-party partnerships, WAN optimization vendors have also developed their own technology to improve integration with network management vendors. Riverbed, Juniper, Cisco, and Blue Coat (Packeteer) have all developed traffic flow export capabilities within their WAN optimization appliances to help customers better understand WAN optimization’s impact on application flows. For example, a large insurance brokerage company exports traffic flow records from Riverbed appliances to NetQoS ReporterAnalyzer to help visualize changes to volume, rate, and bandwidth utilization for every application on the optimized link. This flow export alongside ReporterAnalyzer provides the customer with continued visibility across the link for future troubleshooting, traffic analysis, or capacity planning efforts.

While traffic flow and per application bandwidth utilization information is critical to managing application delivery, it’s only part of the story. The other part is measuring latency of mission critical applications between remote sites and the data center – a more tangible metric of WAN optimization’s ROI and impact on the end-user experience. This measurement can be nearly impossible to obtain since WAN optimization appliances obfuscate application transactions between clients and servers, breaking up the TCP stream.

In order to get around the broken TCP stream problem, we at NetQoS entered into a partnership with Cisco to provide unique technology which measures end-to-end latency over Cisco Wide Area Application Services (WAAS) optimized WAN connections. By integrating our NetQoS SuperAgent technology, WAAS users can get client and server-side data collection and reporting capabilities.

To our knowledge, Cisco and NetQoS currently provide the market’s only solution for accurate latency measurements for client and server communication over optimized links.

WAN optimization is all about improving application delivery. Collecting volume, rate, and bandwidth utilization on optimized applications is only part of the solution. Truly understanding ROI on WAN optimization requires accurately measuring network latency and the end-user experience.

Ben Erwin is technical marketing manager at NetQoS and on Tuesday, May 27, 2008, he will be presenting a Webinar on Building Performance-first Application Delivery Networks with Cisco and NetQoS.

Kevin Davis, a senior consultant at NetQoS, will be presenting a few training sessions at Symposium about SuperAgent, the end-to-end response time module of the NetQoS Performance Center. This will include a training session about how to use time-based network metrics in troubleshooting.  He talks about his upcoming training session below.

In the session, I’m going to be covering the importance of using a time-based metric in troubleshooting, because end-users complain foremost about time.  For example, they’ll say “the application is running slow,” or they believe “the network is slow.”  To users, everything is based on time, that’s what they’re complaining about.  And they’re correct.

It’s very new to many people to think of performance in “time” although that may seem counterintuitive - because most people are used to reading utilization graphs.  With utilization graphs, however, we don’t know if 70 or 80 or 90 percent utilization is necessarily impacting the user experience.  I mean, we buy networking equipment, routers, switches, firewalls, servers, and we want them to be highly – or efficiently - utilized.  Seeing high utilization could indicate a problem – or it could just indicate that you haven’t over-purchased.  So you can have a link at 90% utilization or a router at ninety percent CPU utilization but you won’t know if that’s impacting the end-user without a time based metric.

It’s time-based data that tells you how the users are being impacted.  Sure, the utilization data – the interface utilization, memory utilization, I/O utilization, can often tell what is doing the impact.  But the time base shows you the degree of the impact – the real-world effect on end-users.  With a time-based instrument, such as NetQoS SuperAgent, you can find out where the delay increase is occurring, and whether it’s based in the network, server, or application. 

In fact, you can take a look at time-based data and make a determination very quickly as to which entity is creating the performance issue – the beautiful thing about SuperAgent, in particular, is that it trends by time 24/7, so not only can you determine how your important business applications are being impacted today, but you can go back and look at recurring patterns in performance issues.  You can see if today is worse than yesterday or last week or last month.

In the session, I’ll also be going over how to architect the data center for performance.  Placement of servers that participate in inter-architectures is critical for the health and performance of the application and indeed the data center.  We also talk about how different protocols, for example, Microsoft’s TCP/IP stack, can impact application performance by enhancing or degrading it. 

It’s important for servers that are serving the same application.  For example, a front-end Web server and a back-end Oracle database really should be on the same switch on the same VLAN.  That way they receive optimum service from the network.  If they do leave the switch, they’ll have to contend with bandwidth going up and down the switch links, and they’ll be switched and routed multiple times. 

Based on measurements from customer environments and from our own laboratories, when two servers are on different switches they can have up to 18 milliseconds delay between them.  If we think of that in the terms of network engineers of one millisecond per 100 miles, what in effect we’re doing when we put two different servers on different switches, or two different VLANs on the same switch, we’re making it look like those servers are 1800 miles apart – like one server is in Los Angeles and the other is in Memphis. 

by Patrick Ancipink
Director of Product Marketing, NetQoS

There’s been a lot of growth (and attendant hype) in technology areas like WAN optimization and application acceleration over the past few years, and for good reason. Anything that helps companies speed up and reduce the risk of strategic IT initiatives like consolidating data centers, turning up new branches or serving an increasingly mobile and scattered user community will be popular.

To help with cope with the increasing reliance on the WAN and keep latency in check, there are a dizzying array of vendors and products out there – but if you’re trying to determine precisely which techniques and technologies to implement for your specific needs, the array of vendors quickly goes from “dizzying” to “disorienting” and finally “nauseating.” 

Cisco’s been in this Tilt-a-Whirl™ of a market for a while (and NetQoS has been right there with them) and they’ve taken some big steps recently to provide a more holistic approach that centers on building an “application aware” network, rather than trying to highlight one type of implementation against another for a narrow set of capabilities.

NetQoS started working exclusively with Cisco closely to help customers evaluate, measure, and prove the effectiveness of WAN optimization and application acceleration deployments. As customers are moving from pilot phases into full production, the before/after measurements and comprehensive monitoring are critical to ensure customers are getting the benefits they intended and doing what they need to deliver application performance. 

To help get the word out, Cisco just launched a new section of their web site today that contains a wealth of information about, as they call it, “WAN and Application Optimization.” The downloadable presentation, Cisco WAN and Application Optimization Technical Overview Presentation, puts Cisco technologies (and complimentary ones, NetQoS included) into a useful context with a methodical approach and framework built around four steps: Profile and Baseline, Optimize, Evolve, and Operate. A whole Campbell’s Factory of Cisco alphabet soup technologies are included—WAAS, ACE, NBAR, Netflow, CBQoS, IP SLA, PfR—to show how they work in concert and what role they play in the bigger picture.

There’s also the Cisco WAN and Application Optimization Solution Guide , a very in-depth publication—like 227 pages deep—that is targeted for “technical personnel involved in the specification, design, and implementation of specific WAN and application optimization solutions.” We, here at NetQoS, are proud to have contributed several sections to book regarding the methodology and implementation of network performance monitoring for WAN optimization and application acceleration. 

(If you are looking for some lighter fare, the video on the site tells a nice story in about 6 minutes including an airshow, snowmobiles, windsurfers, and skydiving—interesting choices for demonstrating the criticality of serving video over the WAN.  Then again, some company somewhere has to make the recreational products, I suppose.)

If you missed his presentation at Cisco Networkers, we have a slightly abridged version of Dr. Steve Fulton explaining how to quantify the impact of WAN optimization on application performance, as part of our "Whiteboard Series."

(Our apologies: there is no actual whiteboard used in this video. We just didn't want to go through the trouble of creating a separate "PowerPoint Series" graphic and category.)

If you have questions about the video, please leave a comment below and we'll do our best to answer them.
--------------
More information:

About WAN Optimization:
- What’s Behind Door #2: WAN Optimization and the Transparency Problem
- WAAS Up with Cisco's WAN Optimization Initiative?

Also in our Whiteboard Series:
- The impact of Voice/Video on Data Applications
- The impact of WAN Optimization on TCP Applications
- The impact of WAN Optimization on NetFlow/IPFIX measurements

Tuesday Links On Wednesday: Coverage from the NetQoS/Cisco WAAS announcement, and other stuff.

First, here's what people are saying about yesterday's NetQoS/Cisco announcement:

• ZDNet UK: IT pros get to grips with WAN reports
• EWeek: Cisco, NetQOS Prove WAN Optimization Gains
• Network World: Cisco adds security, monitoring to WAN optimization gear
• Search Networking: Cisco adds monitoring to WAAS
• Network Computing: Cisco and NetQoS Partner for WAN Optimization and Performance Monitoring
• Techworld.com UK: WAN optimisation breaking app monitoring

And… some other things may have happened…

Wired - 27B Stroke 6: ISP Seen Breaking Internet Protocol to Fight Zombie Computers

ISPs, taking action against botnets on IRC, have been redirecting attempts to reach certain online IRC channels. The plus side: It does take care of some bots. The downside - breaking the DNS protocol prohibits access for all users.

"Specifically, Cox's DNS server is responding to a domain name request for an Internet Relay Chat server. Instead of responding with the correct IP address for the server, Cox sends the IP address of its own IRC server (70.168.70.4). That server then sends commands to the computer that attempt to remove malware."

What I'm worried about is the legal aspects - if ISPs can "edit" the type of material passing through the network by breaking DNS, do they lose a common carrier legal status? That is, of course, assuming this type of redirection is even legal.

In related news, some ISPs have been inserting advertisements into web pages - this site from the University of Washington and the International Computer Science Institute should help you determine if that's the case on your network.

The big problem with WAN Optimization and Application Performance Monitoring was that there simply wasn't a WAN Optimization solution on the market that preserved end-to-end performance data, nor a monitoring solution that would work in an optimized WAN.

This problem has been solved.

At Cisco Networkers in Anaheim, NetQoS gave a presentation to hundreds of attendees to make the announcement that we've been working with Cisco to develop a management interface for accurate end-to-end application response time measurement that works on optimized networks. (In addition to the people mobbing our booth, John Chambers, CEO of Cisco Systems, stopped by for a chat and review of what we do.)

Through integrated software on Cisco Wide Area Application Services devices (WAAS), TCP header information is exported to NetQoS SuperAgent (an end-to-end application performance monitoring module) before optimization occurs - preserving that information. Finally, IT organizations can accurately validate the results of WAN Optimization deployments.

(Continued…)

Continue reading "Tracking The Optimized WAN: NetQoS Integrates with Cisco WAAS to Deliver End-to-End Application Response Time Reporting for WAN Optimization" »