With mysteries abounding about the undersea cables cut in the Middle East, Network Performance Daily talked to Eric Schoonover, a senior analyst at TeleGeography, a market research firm specializing in telecommunications supply, demand, and pricing. We wanted to get to the bottom of what's happening with the undersea cables and widespread network outages, and see if there's any truth to the various rumors floating around.

Network Performance Daily: Could you tell me a little bit about the effects of the undersea Internet cable cuts?

Schoonover: The undersea cables that were cut are part of the global network and in fact a heavily used part of it. And as such when they were cut, it limited the amount of capacity connecting the Middle East to Europe. I'm specifically referring to the cuts on January 30th - the first two. And because of that, the Internet and things that relied on the communications to Europe, you know, phone traffic and business-to-business type communications were severely hampered until the carriers that were affected were able to find alternative routing.

Network Performance Daily: When they were able to find alternative routing - was that immediate? Did the traffic find they couldn't get connectivity and just routed around it, or did someone have to pull a switch somewhere?

Someone had to pull a switch. With this amount of capacity, in terms of percentage, there's not that level of restoration available on the direct route. So, for instance, I know an affected carrier that has been quite vocal about the things they have done to restore capacity to their customers - even to the point of having to enter into some short-term contracts to transit traffic around the other side of the world, you know, via India, Sinagpore, Japan to the U.S.

So it does take a little bit of time. And each carrier that was affected responded a little differently in a little different time as well. So anywhere between a few hours to a few days to get service back, depending on the type of carrier and their relationships with the wholesale providers in the area.

Network Performance Daily: Has this increased network latency for those kind of connections?

Schoonover: Absolutely. Two kinds of factors increasing the latency - anytime you go the other way around the world from the Middle East, it's going to add a little bit of distance and distance equals latency, because of that "physics" thing. The other thing is that 75 percent of the capacity connecting the Middle East to Europe was cut, which, when you try to move that type of demand around, then you're going to create congestion on the remaining line.

Between those two factors there is a higher amount of latency and it does take some creativity on the part of the carriers to keep their business customers operating and keep their voice calls at a higher performance level.

The thing to suffer the most would be the Internet. Because that's not as latency sensitive as voice or real-time business communications, the carriers allow it to be more affected by the problems than the other services.

Network Performance Daily: Is there any basis for any sort of conspiracy theory here at all?

Schoonover: No, I don't think so, really. Cables are damaged with relative frequency, and I think that this is more along the lines of coincidence that there were a few different incidences within a couple days than anything else.

Network Performance Daily: What about the two main lines?

Schoonover: Well the two main lines were close enough that it probably was the same event. Whatever cut one most likely cut the other one as well. I know that the initial speculation was that a ship had dragged anchor across the two cables which would very easily snap them. That was later refuted by the Egyptian regulator. You can then look at things like seismic or geological events, something like that.

But most likely because those cables went down together, and they were so close - most likely that's one event.

The other cable breaks in the gulf - there's two others - were separate events that happened within a few days of the initial one.

Network Performance Daily: So if this stuff happens all the time, what can companies do to preserve mission-critical network connectivity and performance?

Schoonover: Finding restoration paths and having existing agreements for having restoration in place is very important, and many carriers have diversity in route and upstream providers, as well as the option to exercise a backup plan. And as we've seen, even if it takes a few hours to a day to get things back up and running with some amount of regularity, that's a result of having these pre-existing redundant relationships available.

I think businesses are getting smarter about that and I think carriers as well, particularly after the Taiwan Earthquake from December [2006], that cut a significant amount of capacity in the inter-Asia region. A lot of businesses quickly realized that their disaster-recovery plans were not sufficient, and went about getting better ones.

The fact that businesses have been able to recover relatively speedily is indicative of good planning to a large extent.

Network Performance Daily: How important are these sea cables to global communication?

Schoonover: Very. A lot of people don't realize, but undersea cables are the backbone of the global communications network. Obviously Europe has a lot of terrestrial cable as does the U.S., but as soon as you need to cross an ocean, the bulk of the traffic is travelling via submarine cable, not satellite.

Network Performance Daily: Well, why couldn't we just use satellite?

Schoonover: Higher latency, less capacity, and more expensive.

Network Performance Daily: What's the most important thing that people are learning from this incident?

Schoonover: I think there's a fragility to any sort of infrastructure, and I think you can take away that businesses and carriers do need to prepare for the unexpected. With the Taiwan earthquake taking seven of eight cables, and this taking two of three on a particular route, there has to be physical redundancy, both geographical and capacity.

But that being said, the carriers knew that and they're working towards it. There's at least four cables being planned and built on the exact same route that the cables that were cut are on. It'll be another year or two until the new cables are operational, but the demand for this type of thing was known and is being addressed, it's just that the timeline didn't work in the favor of the Internet users in the Middle East.

Network Performance Daily: The whole thing - just to get this whole conspiracy thing out of the way - what would it actually take to knock Iran's communication infrastructure off the Internet?

Schoonover: Well, it would take a lot more than what's been done. Really, when you look at Iran's connectivity, while they have been affected by the cable cuts, they are not the most affected country. They have terrestrial connections to surrounding countries, satellite connectivity, and redundant submarine connectivity.

Really, what's been done, if it were a directed attack, it has not been particularly effective.

• Network World: What those oceanic cable cuts mean to you.


• Wired/Threat Level: Cable Cut Fever Grips the Web

How is your company weathering the cable cuts? If you've been affected, let us know how you got back up and running by leaving us a comment below.

Things have gotten slower for many Web users making international communications because of three (or four) undersea cables recently cut. This is especially true for those in the middle or near east, but as the traffic normally reserved for the lines that were cut is now being routed over alternate cables, everyone's traffic is a little affected.

However, for most users, the Internet is merely slower than usual. Not to make light of anyone's current pain, but it is a reminder of the triumph of computer science and computer engineering that is TCP/IP. TCP IP was designed to route around this very type of damage to deliver accurate messages.

Depending on what news reports and analysis you read, there may have been three undersea cables cut, or four undersea cables cut, and these cables were cut over a short period of time by independent, dumb decisions by civilian ships located hundreds of miles apart to drag their anchors along the bottom of the sea to cut through cables armored with steel and polyethylene. However, the AFP news service is reporting that the Egyptian government saw no ships in the area for the 12 hour periods before and after the cable was cut.

An improbable coincidence combined with contradictory evidence? That's breeding ground for conspiracy theory.

This is either an amazing, "win-the-lottery-twice" type of coincidence combined with general widespread confusion, or some sort of deliberate damage. Some on the Internet are suggesting that these lines were cut, possibly, maybe, crazily, as a precursor to a U.S. invasion of Iran.

The "Iran invasion" speculation is fueled by the fact that the router that Internettrafficreport.com uses to measure the amount of traffic coming into and out of Iran is showing a 100% packet loss. As theories go, that's a bit concerning, but that's just one router, and as blog "Cryptogon" points out, other Iranian domain names are still serving up Web pages.

Of course, this panic is caused by U.S. rhetoric regarding Iran. Many online commentators, frightened of the possibility of an expansion of the Iraq war, have taken these outages as fear that the "other shoe is about to drop."

Network Performance Daily, as the vendor blog of NetQoS, isn't in a position to make an editorial statement about war or policies from a U.S. foreign policy angle. But that said, we can tell you that there has never been a war that has improved network performance. While there are many advances in communications technology that have been made as a result of dual-use technology defense spending - TCP/IP among them - the actual act of waging war destroys communications infrastructure. In fact, as far back as electronic communication has existed, destroying the ability of the enemy to communicate effectively was seen as a tactical advantage. Indeed, telegraph poles and the rail lines which brought mail through when the telegraphs weren't working, were targets back during the American Civil War.

Even when this destruction isn't intentional, bombs - even the smartest of them - are indiscriminate. As we see with the Iraq war, delivering even basic electricity when things are frequently blowing up is a challenge.

At any rate, the why isn't quite as important as the fact that the cables are currently disconnected and it will at least take a week or two to get them repaired. In the meantime, now might be a good time to monitor carefully the performance of your global network links to adjust to this new turn of events.

Do you know what's going on out there? If you do, please send us a comment because we have no clue whatsoever.

EDITOR'S NOTE: I e-mailed Nicholas Carr about this post and he suggested that I pick up "The Big Switch" instead of relying on the Network World article, which he suggested might be a bit "sensationalistic." I'll swing by my local bookstore later tonight and see if they have it and will shortly go through it.

By Brian Boyko
Editor, Network Performance Daily

Nicholas Carr (who has kindly mentioned this blog in a post about Ad-block) has written a book called, The Big Switch: Rewiring the World from Edison to Google. And according to Network World, Carr, who wrote an article called "Does IT Matter?" for Harvard Business Review, said in this book that:

"In the long run, the IT department is unlikely to survive, at least not in its familiar form," Carr writes. "It will have little left to do once the bulk of business computing shifts out of private data centers and into the cloud. Business units and even individual employees will be able to control the processing of information directly, without the need for legions of technical people."

Now, we haven't yet read Carr's book and so we can't comment on whether or not he makes a compelling case for the obsolescence of the IT department, and for all I know that quote was taken out of context. But I do believe that it will be a long time before the IT department goes away.

SAAS is a wonderful development, and apps like SalesForce are, to the people that use them, godsends. However, unique company problems require unique solutions - SAAS services are looking to appeal to the largest common denominator. For that reason alone, IT will always have a place in the enterprise.

Additionally, if you want to connect to the network, which you most certainly will have to do to access your SAAS applications, you need network engineers to build and maintain the network - even if it's just for Internet connectivity. And what about application performance?

Google or other SAAS providers will not design your WAN to deliver large backups during off-peak hours, won't get your VoIP service to work with your data applications without clogging the lines, and won't help maintain your company's computer security. (Heck, if nothing else, when a key Ethernet cable gets unplugged, you need at least a sysadmin to find out which cable was unplugged and to physically run down there and plug it back in.)

Relying solely on SAAS is problematic at best. You're at the mercy of another company's quality control - and if the site goes down, so does your business. Your company's data - important and confidential data - resides on another company's servers. Finally, what about capacity planning?

That last one is crucial. You are usually not privy to the capacity of third parties. Larger SAAS services like SalesForce probably scale well and overprovision. But if Carr's thesis - that eventually most enterprise software will be SAAS - holds true, there will be some applications that are further down the long tail and service a much more limited number of customers.

With a typical client/server app, you have all the information there if you need it - the ability of the server, the number of clients, the average traffic per client, and if you have any network management software, you have a very good idea of how much total traffic you can handle. But put that application out in the "cloud" and you no longer can see that information, so you have no idea whether or not you're doing fine or teetering on the edge of a major slowdown in the service. It completely negates any possibility of meaningful capacity planning.

Sure, it shifts the blame from the IT department to the SAAS provider, but ultimately, it's the same thing: less productivity, less on the bottom line.

If Carr's thesis is that SAAS is going to play more of a role in enterprise computing in the future, we can't help but agree. But to say that there's no role for IT in a future with more SAAS applications is assuming far too much.

By Brian Boyko
Editor, Network Performance Daily

I'm sure most of our readers can sympathize with the protagonist in this Daily WTF story, "Illicit Process Improvement." (Indeed, it reminded me of quite a few scenarios from my mandatory high school "computer studies" courses.) Most people who have worked in the bowels of corporate IT departments can sympathize with the situation: Lowly but technically savvy person discouraged from making minor improvements because of a major change, which is perpetually "on the way."

And it does seem that the big project is almost always either perpetually "on the way," until it's forgotten or the project's sponsors have to admit defeat, doesn't it? Indeed, Infoworld has written "On average, about 70 percent of all IT-related projects fail to meet their objectives." That's a staggeringly high number.

Certainly, IT failure rates are one of the reasons it can be so hard to explain how to get business decision makers to invest in IT. I mean, think about it. Would you invest in a business where 70% of the products failed?

This is one of the reasons that IT departments need to quantify the business gains from successful IT initiatives, in order to justify the investment the business makes in IT. And we've talked about that before, especially as it relates to quantifying the value of network performance improvements. But if it's good to quantify your successes, wouldn't it be even better to have more successes overall?

You could argue that IT is just too complicated; that there are too many pressures and personalities in the IT room, and that technology upgrades are just complex and prone to failure. I doubt it though. Sure, WAN Optimization and VoIP implementations are difficult and technical. But commercial satellite launches are technologically complex, and I'll bet you failure rate is less than 70%. Indeed, the Indian Space Research Organization is talking about a 5% launch failure rate in 10 years.

Okay, so it's a false comparison. But if the IT guys are bright people - why does everything seem to fall apart?

I think that it's because of three things.

First: Often, projects are started without a clear understanding of the company's needs, and without a clear sense of the greater goals of the project.

I don't want to get started in on a recursive loop of existential navel gazing; lord knows I've done that too many times in my lifetime. But I think that many projects are started without a clear answer to the question: "Why?" When the project is successfully completed, what will it have accomplished? Is that goal one which will ultimately benefit the business in some capacity, by reducing cost or increasing revenue? Often times, we find ourselves taking on projects without having the purpose in mind - the project itself becomes its own purpose.

Now, this instinct often serves technical people well - we approach technology as an art form, with no particular purpose needed. This is why we were putting together Linux boxes out of old computers in our freshman years of college (or high school) and learning all we could - even though it might have been more productive to stick with our PCs at that time. Technology for technology's sake.
So as we get bogged down in the technicality of things, we ignore the broader questions of why.

And while it probably means more of the dreaded "meetings" which keep us away from our servers, databases, and wires and force us to spend time in boring, dull human contact before any project begins, it's probably a good idea to establish what the ultimate purpose of the project is. If the project can no longer meet those goals, if the project is not the best way of meeting those goals, if the goals become irrelevant - then it's time to change the project to meet the new goals, not the new goals to meet the project.

Second, when the project is underway and a deadline passes, the deadline is often pushed back with no ill consequences.

Projects often limp on for years that way. Furthermore, if you know that a deadline is going to be extended, you're more likely to put those projects on the back-burner, instead of giving them more direct attention. Okay, sometimes the task is harder than anticipated, or more problems creep up than are expected - these things happen. But if you can't meet an incremental deadline for a phase of the project, then you have to ask whether you'll be able to meet the final deadline; and if not, how that impacts the key goals - will the project even meet those goals now?

In short, a missed deadline is a reason to re-evaluate the project - not a reason to re-evaluate the deadline.

Third, there's a tendency for IT planning to develop overarching, long, huge, revolutionary solutions when small fixes are the most efficient solution.

Just speaking from personal experiences, I could have just bought a TiVo instead of going through the steps required to build my own MythTV box.
In the story mentioned at the top of this article, there was a solution that marginally improved the process that was discarded, because of fear that it would interfere with a larger project that never quite materialized. The larger the project, the greater the number of things that can go wrong; and thus, incremental steps of organic improvements are often the best - if not the most sexy - of solutions.

The other extreme, of course, is to keep patching a legacy system far past its workable prime. (A good rule of thumb for when to do the whole thing over again is when you find you can't fix one thing without breaking one other.) But by and large, people often overlook simpler solutions in the pursuit of their own grand plans.

Ultimately, reducing the failure rate in IT projects comes down to the paradoxes of being able to meticulously plan a clear path and being able to recognize opportunities and improvise when they arise.

Of course, these are just my opinions, and I could be wrong. Let us know what your theories on the high failure rate of IT projects are in our comments section below. Of course, we are particularly interested in those that pertain to networking and performance management.

Also, just a quick reminder, our New Years Resolution contest ends tomorrow, January 3rd, 2008, which is your last chance to submit your Network Performance Management Resolutions for 2008 for the chance to win a Nintendo Wii, TomTom GPS system, iPod Shuffle or iPod Nano.

"In fact, I was talking with someone the other day," said Jim Metzler. "I don't need to be dramatic, but he said to me, 'Jim, I look at Web 2.0 the way I look at global warming. We're just beginning to realize how serious global warming is and take some steps now. We're not there yet on Web 2.0, but it will have a dramatic impact."

We talked a little bit about how broadband is causing end-users to expect more from the Web apps that they use for work, but here's a basic recap: If a user is used to waiting less than 5 seconds for a YouTube video, they may not be as willing to wait 30 seconds for a database. Things are getting faster, and as such there should be a new emphasis on providing performance.

We are used to information in real-time. Our growth of interconnectedness - indeed, the growth of community - has driven us to new expectations.

So we talked to Jim Metzler about whether Web 2.0 is creating new requirements in network performance.

"I think they will once they get more broadly deployed. I actually think that things like SOA and Web Services, Web 2.0, are going to significantly rachet up the need for a more dicisplined performance management, but I don't think people realize it yet…. I think we're still kind of kicking the phrases around. People are saying, 'Oh, Web 2.0, that's all marketing hype, no one knows what that means, yadda yadda yadda' So I think we're still in the denial stage. But I think that, over time, it will have a significant impact on the need for performance management and how we do performance management."

So, what can companies do about Web 2.0?

"I think where's there's SOA Web services, the bottom line is, for starters, we can't chart a course to improve, if we don't know where we're going. It's as simple as that on one level. So we need to continue to educate ourselves as to what exactly Web 2.0 is. And you're not going to be able to get a very precise definition, but you begin to read and see some commonality. 'Is my company heading in that direction? If not Web 2.0, how about these SOA Web services?'"

"I think that on the infrastructure side, to understand the evolving application disciplines, architectures, whatever you want to call it, not, so to speak, just in general but as their company is evolving to it, to figure out what that means for them - Initially it just comes down to guessing at the high level picture and then coming down closer to the ground. As you have some of the monitoring tools that people are deploying, they begin to place more emphasis to understanding the flow of data in an application."

"Becoming more application aware today, not just what applications are running on the network, (that's a good starting point,) but how do they actually transfer data and where are the performance roadblocks? So, it's kind of getting a handle on today while beginning to understand where we're going to evolve to over the next one to five years."

When asked if there was anything else he wanted to mention, Jim Metzler said: "Let's hope the Red Sox can beat the Indians."

By Brian Boyko
Editor, Network Performance Daily

Slashdot recently linked to an article from MacWorld showing that the amount of time that people spend watching online video has steadily increased. (In other news, water is wet…) Google's YouTube and Google Video served up over a quarter of all internet videos.

I think we can assume that a fair percentage of them were watched from corporate networks. Not just because of recreational use but because video is a very compelling medium that can convey work-related information, sometimes more quickly and more accurately than text alone.

For example, our Whiteboard Series was created with the expectation that people would watch our videos on WAN Optimization and VoIP from work, where they would find the information most useful.

One really can't just block YouTube, or Veoh, or Yahoo Video and expect blocking it to solve the problem of tying up vital bandwidth, because video is increasing not just as a 'bandwidth hazard' but as a method of communication. And it's only going to get more bandwidth heavy - and more useful - as MPEG4+ACC "Moviestar" Flash Video, or WMV using Microsoft's Silverlight increase the quality of online streaming video.

Don't think there won't be content producers - like us - taking advantage of this as well. High definition full-fledged video cameras cost less than $1000 these days. A flash-video "YouTube camera" can record 720p HD for less than $200.

The way to prepare for this is to have good QoS policies in place, so that the day-to-day business data transactions aren't interrupted or slowed when people access online streaming video - which is quickly becoming a necessity.

One big thing that complicates this is hard shut-off date for the end of all analog TV transmissions in the U.S. on February 17, 2009. It is possible to use a converter box to use an older TV with the ATSC standard - but most people will probably get a high definition television instead. High-definition television will prompt high-definition content. That includes home movies.

Right now, High Definition home video cameras are sold to computer geeks, early adopters, and indie filmmakers. They will be more widely adopted when most families have a high definition TV set and want to play back home movies. And as many YouTube videos are harvested from the ranks of home movies, it is possible to then imply that there will be demand for a high definition video hosting service.

That's going to mean more bandwidth usage. QoS policies become crucial.

By Brian Boyko
Editor, Network Performance Daily

Right now there's a bit of a brouhaha about Comcast high speed service. Many Comcast customers are finding themselves cut off from the service because of excessive usage.

To be fair, I was unable to find any reference where Comcast says that their broadband package is "unlimited." However, they fail to disclose what, exactly, "excessive usage" consists of in their Acceptable Use Policy.

I don't have a problem with Comcast limiting bandwidth. There's only so much traffic that their servers can handle, so much that can go down their pipes. Theoretically, limiting the use of the heaviest users would enable better service for the vast majority of users for whom speed is more important than volume.

(Of course, the cynical assume that Comcast is dropping high-usage customers because they're the least profitable and that supporting those users would require investing more in bandwidth and infrastructure - but we'll leave that theory alone for now.)

What I'm concerned about is people suddenly being disconnected from the Internet after passing a line that they know nothing about. I'm sympathetic - my Internet access was cut off without warning back in 1998 at The College of New Jersey, and that cost me a pretty well-paying part-time job as a Web designer. (There were other reasons, but this was a significant reason that I decided to transfer to New Jersey Institute of Technology the next semester.) If my home internet access was cut off today, I'd be at a serious disadvantage with my job editing this blog!

But it also worries me because I can't imagine this happening to a corporate customer. If an IT department asked "how much bandwidth do we have," that information would never be withheld from them. You can't do any meaningful capacity planning if how much capacity you have is kept hidden from you.

Disclosure is obviously the most important step, but there are other options that Comcast could take. Instead of cutting users off, it could throttle down speeds once a customer produces a set amount of traffic - The customer still has access to the Internet, but it doesn't take up quite so much bandwidth. While downloading Linux ISOs via Torrent are going to take longer, viewing YouTube and talking on Skype shouldn't be affected by reasonable, but lower, bandwidth caps.

At any rate, if Comcast simply couldn't keep up with the demand, then perhaps they need to consider billing as a pay-as-you-go service. Sure, we did away with hourly billing around when AOL switched to flat-rate service in 1996… but certainly, paying for the service that you use is probably very appealing to the vast majority of people paying $50 a month to do nothing more than check e-mail and Web browse.

Then again, there are other solutions which are probably preferable. Namely - improving the performance of Comcast's existing infrastructure, or adding capacity to Comcast's existing infrastructure. Apparently, though, both those solutions are more expensive than suddenly dropping a few customers from the rolls and engendering ill-will.

This phenomenon isn't limited to the Gummi Bears. There were protests in Mexico over the rising price of corn tortillas. German beers are feeling the pinch as farmers trade in hops and barley for the more lucrative rapeseed and corn. Jolly Time Popcorn isn't feeling so jolly after corn prices went up 70 percent. Between the double whammy of increased cost of corn and increased cost of every other crop because farmers are switching to growing corn instead, it's gotten to the point where it's cheaper to feed livestock, such as pigs, human snack food, according to the Wall Street Journal.

Back to network performance. Consider for the moment, that the path of the food we eat, from raw ingredients to our supermarket shelves consists of a "network" of sorts, this is a classic case of a sudden, unanticipated spike in demand from another endpoint in the network that is wreaking havoc on the network itself. Or, farmers switching to corn at the expense of other crops seems like a classic case of over provisioning one "application" on the network at the expense of all others.

These changes may have seemed insignificant at the time. Many disruptive changes do, which is why you need to have good visibility into your network - whether it's an enterprise network or a food distribution network.

Even a slight increase, for example, in network demand has a number of ancillary costs that many people don't look at. Greater demand of resources doesn't just require more bandwidth. It may necessitate greater processing power, which necessitates more hardware, which necessitates more power and more cooling.

I mean, when even the cost of alternative fuels are going up, many more people are going to be telecommuting from their homes instead of driving or flying in for business. If you're not prepared for a change like that by being aware of how your network is being used, and what changes are coming down the pipe, your network is in just as much trouble as the Gummi Bears are.

During a recent NetQoS - Cisco WAN Optimization Seminar Series, and to some extent at Interop, NetQoS launched a survey regarding WAN Optimization. We found some interesting things:

Over 90% of the survey respondents said that it is either important or very important to be able to quantify accurately the results of WAN optimization.

Over 80% say it is important/very important to have integrated WAN optimization and performance reporting.

We also found that most respondents – 60% - believe that the most relevant measure of WAN optimization impact is in application and network latency. 30% believe that link utilization is the most relevant measure, and 10% believe that the two are equally important, with a handful of respondents saying that protocol distribution is the most important.

What this tells us is that many enterprise IT organizations do not want to deploy a WAN Optimization solution that is going to break their application and network performance monitoring. However, WAN Optimization devices perform local TCP ACKnowledgements, thereby confusing performance monitoring and making it near impossible to accurately quantify the results of WAN Optimization.

We go into this challenge more in “WAN Optimization’s Dirty Little Secret” and John Mao and Ben Erwin have uploaded some videos in Network Performance Daily’s Whiteboard Series to illustrate the points, but basically, many WAN Optimization devices (WOD) split a TCP/IP session between a client and server into three separate sessions – a client segment, a WAN segment (or “channel”), and a server segment. But data center-resident passive network monitoring tools assume only one TCP session between the client and server – which means that when WAN optimization is deployed, they only have visibility into the server segment response time – between the server and the data center WOD. So, visibility into all the components that make up end-user application response times, including network round trip time and data retransmission time, is lost.

If ultimately, IT is about application delivery – the reliability and speed with which you can deliver applications to the end-users – then forgoing application and network monitoring is not an option. We’ll have more on this problem next week. In the meantime we look forward to seeing you at Cisco Networkers in Anaheim.

--------------
More information:

On Quantifying the results of WAN Optimization

WAN Optimization solutions are designed to do a couple of things: increase the performance of applications running over the WAN by reducing latency and help companies achieve efficiencies in bandwidth usage. This can help avoid costly infrastructure upgrades and reduce the downtime and lost revenue associated with poor network performance.

For most companies, a big value proposition of WAN optimization is data center consolidation. If you can make your WAN performance rival that of your LAN, you can do away with remote data centers and repurpose or liquidate the expensive hardware in each branch office.

It also simplifies making backups in preparation for disaster recovery because much less data needs to travel across the link in order to get a full backup of the branch office to the home office. It becomes feasible to back up key data remotely on a regular basis. (The alternatives are to saturate the link with a scheduled backup, hire on-site staff simply to do the backup, or trust that the end-users will back up their data locally - which isn't much of a guarantee.) Keeping your data backed up and in one central location also means that it will be easier to verify compliance with government regulation.

There is also a "green effect" as it may also cut down on power requirements too - similar jobs done by separate servers in each branch office can now be handled via a single server at the home office, running virtualized server environments. While that one server requires more CPU cycles, chances are the tradeoff will result in lowered electricity needs. And of course, it eliminates maintenance costs for all that hardware, and the ability to keep your IT staff in your home office rather than sending them on planes to the four corners of the earth when something goes wrong.

There are numerous trends driving the demand for WAN optimization. So, how do you know where you can get the biggest improvements from your investment? Which applications will benefit the most? And, what about the pitfalls? One of the downsides to WAN optimization is that is obscures end-to-end performance monitoring for TCP applications because it breaks the connection between client and server into three separate segments. Most WAN appliances also obscure Netflow data which is used for security and traffic analysis purposes. Traffic prioritization via QoS can also be interrupted. Some WAN optimization solutions address these concerns. Others do not.

-----------------------

Network Performance Daily will address these questions in a series of upcoming posts on WAN Optimization. Subscribe to our RSS feed to get weekly updates. Also, chime in with your thoughts on what you hope to get from deploying WAN Optimization in your organization. Feel free to leave comments below.