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.)

Windows Server 2008 officially launched today with little fanfare; but the new enterprise-class operating system has been eagerly awaited by people who eagerly await operating systems, instead of going out and having a good time with their lives.

NetworkWorld has a thorough review of the W2K8 OS up on their site, but spends a bit of time tracking the performance of the network input output in various tests.

We tested network I/O performance using both emulated I/O and various traffic/assault tests (see How we did it) and found Windows 2008 Server performance has improved - and especially improved when Vista is the client….

The new stacks also have the ability to dynamically respond to communications latency in network connections as they possess the ability to dynamically change TCP packet window size, which allows a communication channel to be more efficiently stuffed with data.

In our testing we found that under light loads, the effects in terms of speed of tasks like copying folders, streaming media and loading complex Web pages aren't strongly demonstrated, but the effects under heavy loads, however, favors performance for Vista, strongly. Depending on the mixture of I/O (but pronounced under streaming media and heavy file copying), Vista can be as much as 43% faster than Windows XP SP2 in copying operations and 18% faster in opening concurrent streams.

This also means that there's a two-class affinity for clients of Windows 2008 Server Editions - Vista and everyone else, including Windows XP SP2, MacOS (we used 10.4.10 and 10.5.2) or other SAMBA clients that use SAMBA 3.0.2+ connection methods. If you have a client with the new stack, you're more efficient, and, therefore faster under higher loads, but you're a second-class citizen if your stack isn't up to date.

What I'd like to know is what, specifically, makes W2K8-server/Vista-client combinations so powerful. Is it just the compound TCP protocol? Are there kernel optimizations for network data processing? (I don't have the technical knowledge to address those questions, I'm hoping that my readers will be able to share their theories and the results of any tests they may run.)

At any rate, while W2K8 is a significant milestone release, good or ill, the history of server software distribution usually means a slow rollout period - to the point where naming your operating system by year becomes almost a bitter irony; chances are most companies who use W2K3 will want to roll out W2K8 in 2009 at the earliest.

Just a quick post today - I wanted to call attention to an article by David Talbot of MIT's Technology Review, entitled "A Technology Surges" about how DARPA produced a kind of wikified Google Maps for Iraq-stationed patrol commanders.

The application, called the "Tactical Ground Reporting System" or, because the military loves acronyms, "TIGR" - is a wonderful thing. Junior officers who command patrols study data telling them about key buildings, location data on past attacks, etc., and then they can add the information they found out on their patrol to the map-centered database for the next patrol to study. Using cameras with embedded GPS technology, they can take pictures of the scene on the ground and add them to the database as well.

And of course, the system was designed with the Iraq theatre's networking performance needs in mind.

Deploying it widely required dealing with two main challenges raised by Iraq's spotty data connections: how to synchronize scattered copies of the same database, any one of which a returning patrol leader might modify, and how to give soldiers multimedia information without crashing the system. One solution was a network that carefully rations out bandwidth. For example, the default mode for any photograph is a thumbnail version. A soldier has to click on the thumbnail to see a larger version and will get a response only if bandwidth allows.

With future advances, such a database can be updated and accessed live from the patrol in-country.

The next step, says Maeda, is to install it in Humvees and other military vehicles, allowing soldiers to download and act on new information in real time. Some of these vehicles already have some low-bandwidth connections, and Maeda says DARPA is working on ways to make the software work using these thin pipes.

It's not that any of this should sound unfamiliar. Google Maps mashups for sales data, tourists, and even MMORPG players are used in a similar manner for similar purposes. The significant thing is overcoming the challenges in an unstable, wartime environment where network performance is never a certainty.

by Brian Boyko
Editor, Network Performance Daily

The release of Adobe AIR today might just bring about major changes - both good and bad - for network performance. AIR is a way to produce Web apps that can be run as desktop apps. It is cross-platform and relies, like Java, on a just-in-time compiler and an interpreter of application bytecode. There are interpreters for Windows and OSX, and a Linux interpreter in development.

"It allows Web application developers - or just application developers - to use the Internet technologies they know, whether it's Flex and ActionScript to target the Flash part of AIR, or Javascript/HTML/CSS to target the AJAX part of AIR," said Phil Costa, director of product management at Adobe. "It allows them to take those applications and run them on the desktop."

Costa explained that through AIR, (depending on what the application does and how it is coded,) companies may theoretically experience a lowered amount of data throughput and an improved network performance.

"Today a huge number of corporate networks are moving towards browser based applications, and one of the extra bandwidth requirements that it puts upon the network is that every time you access a [Web based] application, you need to download it. Whether that's HTML or Javascript, or all kinds of Flex and Flash content, that needs to be pulled over the network. Having the application installed locally avoids that. All that will be going forth is the actual data that you're trying to access."

"We've done tests with some of our customers where they've seen our bandwidth [usage] go down for Internet applications in general, because unlike a Web site, which creates both the content and the formatting of the content, most AIR apps are just passing the information back and forth instead of refreshing the page each time."

"Now, depending on what the application does, it may actually add [to] bandwidth requirements for the network as well. One of the things that applications do, is run in the background and connect permanently to a data source's real time streams, or frequently check for data. That could increase the bandwidth requirements. But that's more about what the application specifically does than anything specific about AIR."

AIR's capabilities allow for offline usage as well, which will likely prompt more demand for online apps as the major drawback of SAAS - inaccessibility - is mitigated.

"In addition to giving the developers and then end-user of the application the convenience of launching the [Web] application like any other desktop application," said Costa, "it gives them additional capabilities that they didn't have when they were targeting the browser, such as local storage, either in flat-files or structured storage like a SQL database, which is embedded in there, or drag-and-drop integration with the file system, and cut-and-paste as well as the ability to take data or content offline, and run it when they're on an airplane or just not connected to the network."

"The runtime provides a whole set of APIs for notifying the application when it is on and offline, and so the developer can implement behavior that accounts for that; in many cases what we see is that the developers are caching some of the information offline, so that if the user takes it offline, it will still be available."

"To give you an example… one of our customers, Anthropologie, built an online catalog that lets people browse through things they have, and they built an AIR version which lets customers make little notes to themselves about the product, and rather than store them on the Anthropologie Web site, it stores them locally. The customer can put notes on things the same way they put stickie notes on an actual physical catalog, and they don't have to share that information with the Web site, so it's private to them. It also means, from Anthropologie's standpoint, that they don't have to create massive databases to store that information."

Costa said that Adobe hopes that there will be AIR apps on mobile phones, something that there's no specific date on, but which is on the Adobe roadmap.

Wondering about the traffic that traverses your enterprise network? Concerned that malicious or recreational traffic is eating into your precious bandwidth? Just want to know if traffic trends are impacting overall application performance? Get answers in this live NetFlow Webcast on February 26th, 2008. NetQoS expertise will to give examples of how to use network behavior analysis to improve end-user application performance.

(The webcast on how to use network behavior analysis to take over satellite mounted lasers originally scheduled for that day has been postponed. We deeply apologize to Mr. Blofeld, and hope that he can catch our next webcast on the subject.)

Network behavior analysis and anomaly detection have enabled those organizations that use these tools to become more proactive - and we'll have our experts John Mao, Product Manager, and Patrick Ancipink, Director of Product Marketing, talking about the trends driving IT decisions in the industry.

Additionally, we'll talk about the continued importance of Netflow and IPFIX reporting for sustained and optimized application delivery, and those of you who deal with flow-reporting as a major priority will probably find this upcoming Webinar particularly instructive.

We'll also be talking about planned updates to the NetQoS product lines at this Webcast for the benefit of our current and prospective customers, and all attendees will receive a copy of the Aberdeen Group's recent report, "The Real Value of Network Visibility." (We thought about sending you all NetQoS koozies, but thought you might like this better. Though if you ask for one, I'm sure we can find some.)

You can register for the Webcast here. Attendance, and our supply of koozies, is limited. The Webcast will be held on February 26th, 2008, at 12:00 noon. CST (10:00 a.m. PST/1:00 p.m. EST/6:00 p.m. GMT-UK.)

If you're just itching to get a few tips on how to use a NeFlow analysis and reporting tool to check out network traffic and conduct network behavior analysis, we present a few tips on our NetFlow analyzer page.

What network engineers need to know is not what they already know. This is because if they already knew it, they wouldn't need to know it, after all, because they already know it. And if they didn't know it, well, then, they wouldn't have known it, then, unless they've forgotten it, in which case all bets are off and might as all pack it in and follow our dream of writing Monty-Python style British comedy making fun of tautological banter.

But in a more metaphorical, less tautological sense, the critical metrics for measuring network and application performance are shifting; and require new information in order to manage effectively.

Much of what is now considered an older generation mentality is the fault oriented approach network management. "Send me an e-mail when the router goes down." That was the kind of proactive notification that engineers were looking for.

But technology has advanced to the point where complete and catastrophic failure is a much less likely scenario. Built in redundancy in the form of redundant network connections, NIC cards, and power supplies, (not to mention redundant network connections, NIC cards and power supplies) mean that fault is no longer the biggest driver of network maintenance needs. In fact, you could say that built in redundancy in the form of redundant network connections, NIC cards, and power supplies, mean that fault is no longer the biggest driver of network maintenance needs. To reiterate…

The problems that are being faced today are more along the lines of application performance, e-mails that take forever, Web sites that are hammered with traffic, and FTP batch transfers that get timed out. These aren't about questions of whether the application, router, or server is up and running, but whether the application, router, or server is running efficiently.

Network engineers now have to look network behavior analysis to spot anomalous traffic patterns that either threaten or coincide with application performance problems. Additionally, in order to fix the problem, network engineers need to analyze those patterns so they can determine what kind of performance problem they're having - a mis-configured router, inappropriate P2P traffic, malware, etc. - and then be able to quickly fix it. After all, none of these examples would bring a router down but they might cripple business-critical applications to the point the end-user feels that it's not usable.

For this reason there is a burgeoning industry in network behavior analysis appliances, devices, and programs that look at the live data for anomalous behavior and alerts the network engineer that there may be trouble a-brewin. That way, a network engineer can then know what they need to know - the things they didn't know until they knew it.

It was almost inevitable in the age of the digital camera; Polaroid is discontinuing production of Polaroid film for its once ubiquitous "instant" cameras. For many, this means the loss of nostalgic memories with a family camera.

However, while digital cameras have filled the need for instant photography more effectively than the Polaroid camera could have done, the analog processes of light + film + developer fluid in a handy-dandy photograph-sized pack found interesting niche industrial uses - industrial uses now impacted by the end of Polaroid's film.

For example, doctors used it in medical imaging. Archeologists used the portability of Polaroid in combination with X-ray photography to examine ruins without disturbing them.

Additionally, Polaroid film is impossible to retouch without there being signs of alteration. This meant that law enforcement and criminal justice relied on them.

In these industries and others, the Polaroid camera filled a niche that will now have to be filled by digital technology; and in many cases, that digital technology will place new demands on the network.

For example, medical imaging requires very high detail; shots on film provided a low-cost way of providing that detail. Equivalent digital technology would produce images that have extremely large file sizes. Instead of passing the photo instantly from doctor to doctor, the files would be transferred from doctor's computer to doctor's computer - or to a photo printer. Since a photo printer of sufficient resolution would be rather expensive, it is likely that a hospital might only have a few of them, networked together. And, of course being forced to move to digital from film, doctors would take the new capabilities of digital to converse with doctors across long distances - that means traffic on the WAN.

One of the medical companies that has already gone "filmless" is CliniTech - they're using NetQoS's end-to-end application performance monitoring tools to track the performance of their digital radiology application, so that they can make sure all the doctors and nurses can view these digital images from anywhere in their healthcare system. They may have been forced to go digital by Polaroid's obsolescence, but once there, the advanced applications of digital technology will then become expected.

The archeologists are in a similar situation. Instead of taking photos back with them to be analyzed locally and taken back with them on the flight to their laboratories, once they have been forced to move from Polaroid to digital cameras, they will probably then use satellite communication to send those photos back to remote colleagues immediately.

Perhaps most complicated of all are the law enforcement personnel. A move to all-digital photography would require some sort of watermark-like digital signing to certify that images were not retouched. The networks that these images reside on will have to keep a very tight audit trail which includes EXIF-type data for the full path of the image in order for it to effectively be used in court. And, of course, they would need to transfer the images over a secure network to prevent people from altering or destroying digital evidence.

It just goes to show you that even things that you may never have thought about can impact network performance in ways that are nearly unforeseeable.

How are you being affected by the Polaroid film discontinuation? Leave a comment below.

(Special thanks to Carol Schiraldi for giving us this story lead.)

by Brian Boyko
Editor, Network Performance Daily

By now, everyone will have heard of Microsoft's hostile takeover bid for Yahoo, and of Yahoo's board rebuffing the offer. What people may not be thinking about would be how a "Microhoo!" would affect IT application performance planning.

While it's clear that Microsoft, having been unsuccessful in promoting its own software-as-a-service offerings, is now trying to buy their way into this market simply by buying out the market leader, it shows how seriously Microsoft takes the SAAS space.

Yes, it's Yahoo, and not Google, that is the leader on online SAAS solutions - at least as far as consumers are concerned. Google gets more searches and does better with online advertising, but Yahoo Mail, Yahoo Groups, Yahoo Flickr, Yahoo Del.icio.us, Yahoo Voice, Yahoo Upcoming.org and all of the other services that are owned by Yahoo more than make up for Yahoo's second banana status in search - to the point that Yahoo has more users and page views. Typing the word "mail" into Google returns Yahoo! Mail as the top search result - over Gmail. Seriously. Try it.

One reason, perhaps, why Microsoft might want Yahoo!

It's not a sure thing of course, that Microsoft will build SAAS applications after a Yahoo acquisition, or that those applications will become commercially successful. It seems like a paradox that Microsoft has not been able to do well in SAAS development when SAAS applications discourage open-source solutions. Sure, there are open source SAAS applications but the overhead and cost of hosting and maintaining SAAS infrastructure favors larger, established proprietary software vendors, with more money to sink into the project.

This also provides enough reason for those who predict that Microsoft would somehow "ruin" Yahoo's online-app offerings to pause and consider what would happen Microsoft's business strategy combined with Yahoo's online development and marketing.

As we've mentioned on Network Performance Daily before, you don't stop thinking about application performance once applications move out from the data center to the Internet.

The conversion of Microsoft applications - which are still in a strong position in the enterprise - to SAAS applications would mean big changes to IT planning. When you move an app from the Data Center to the cloud, you're giving up control of the infrastructure, and submitting it to the vagaries of the Internet. As we've seen recently with the undersea cables, it's not always that great an idea to rely on consistent Internet performance for business applications.

Additionally, it's disconcerting when you realize data, in SAAS solutions, is typically stored online. This makes SAAS solutions convenient, but it also makes SAAS solutions particularly prone to vendor lock-in. Salesforce is a wonderful app, but I wouldn't want to switch to another CRM manager, online or offline, if all my data was already in Salesforce.

So with this sort of lock-in, IT managers have absolutely no back-up plan if things start to go wrong with their application performance - whether it's in the SAAS application's data center end or the Internet links in-between the SAAS data center and the enterprise data center. There's even less margin for error.

In addition to making sure that each of the offices on the WAN has the connectivity and performance it needs (after all, even in the hypothetical situation where all the applications a company uses are online, someone still has to make sure the Internet gets to every computer) network engineers in the future may be evaluating solutions by running hypothetical scenarios of what would happen if particular Internet links or nodes went down for a period of time, and recommending particular SAAS services based on "worst case scenario" disaster prevention and recovery capability.

Of course, I could be completely wrong about that - prognostication is fun, but invariably you look ridiculous with the passage of time. But if there's one thing is certain: Whether or not Microsoft is ultimately successful in its bid, the bid itself is a herald of new challenges for IT.

Recently, Network Performance Daily did a story on the Cisco Nexus 7000 switch, which had recently been announced by Cisco and will likely be a very important piece of enterprise hardware.

After our article, Douglas Gourlay, the Senior Director of Marketing and Product Management of Cisco's Data Center Business Unit, contacted us and pointed out that we were mistaken about some of the capabilities of the Cisco Nexus 7000 and so we invited him to do this podcast with us.

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.