Cisco announced Cisco EnergyWise at Networkers Barcelona; a software upgrade that allows users of Cisco Catalyst routers to control the energy consumption of pretty much anything that has an IP address. According to the promotional literature and video, you can limit power based on schedules, while allowing exceptions – for example, if a particular employee swipes an ID card to gain access to the building on a weekend, you can turn on the power only in his office until he signs out.

“Why does my toaster need an IP address?” is no longer a joke.

Rob Aldrich at Cisco’s datacenter blog wrote about it, and much of what he has to say is worth a look. If nothing else, the video is kind of cool.

One of the main benefits to data center consolidation and server virtualization is to decrease the power draw of the company overall – and it’s been argued that IT will have to handle electrical facilities in order to limit power consumption without creating problems with network performance. If facilities and IT do not communicate, you could end up with a real disaster, like, in a worst case scenario, someone trying to be too eco friendly and turning off the air conditioners in the server room over a long weekend.

While energy management via IP may seem like yet another thing – in addition to security, VoIP, and of course, network performance – that the network engineer will have to manage, the cost savings can be substantial over time. The trick is that energy management only occurs on things that have an IP address. Since it’s a pain in the butt to try to subnet every single light bulb, this may be an incentive for IPv6 adoption.

The headline read: “Bill Gates Unleashes Swarm of Mosquitoes on Crowd.”

I blinked, rubbed my eyes, and read it again.

The headline still read: “Bill Gates Unleashes Swarm of Mosquitoes on Crowd.”

It wasn’t the Onion.  This was too weird to be the Onion.  Bill Gates, one of the richest men in the world, and certainly one of the most well known, decided that in order to make a point about empathy, he would release a jar of mosquitoes at a talk he gave at the TED conference on malaria in developing nations.

Now, I’m all for Bill’s charity work; and you have to admire a guy who uses the money he’s made towards good deeds. But I’m a little bit worried that Bill Gates may have finally decided to make the full-fledged leap from eccentric billionaire to evil genius.

Speaking of Microsoft and full-fledged leaps, IT Business edge reported that while users of Windows XP will be eligible to upgrade to Windows 7, it only means that Microsoft will sell you Windows 7 for a reduced price.  XP users will have to reformat their hard drives to use Windows 7.

This is major. 

For various reasons, Vista has not been a popular operating system compared to it’s older brother, XP; in fact, by last summer, Vista had a grand total of 8.8 percent of the market.  XP is at 87.1% of the market.

Though it’s easy to blame Microsoft, there has to be a technical reason why there’s no upgrade path from XP to Windows 7.  You don’t last long as a company if you make things harder for 87.1% of your customer base to upgrade. 

If your company is in the 87.1% - and statistically speaking, that’s more than half – this will probably have a huge impact on companies IT, as companies repeat the processes of reformatting, installing Windows 7, reinstating data, and reinstalling apps for every XP computer.  Perhaps even network engineers may have to put projects on hold as they get drafted when the enterprise decides to upgrade. 

Second – backing up the data on all those computers before the reformat – especially in the post-Enron Sarbanes-Oxley record keeping era – will be crucial and easy to screw up. Additionally, backing up all that data to “the network” will increase the amount of traffic on the LAN. 

So network engineers are going to have to answer some hard questions: Can the hard drives be backed up via the LAN without impacting application performance?  In what ways can we use scheduling and packet prioritization to minimize the impact on application performance?  How much money will the company lose due to degraded performance; would it be cheaper to simply buy external hard drives for everyone in the company?

(And if you don’t know the answers to these questions, shouldn’t you?)

Shamus McGillicuddy, not to be confused with the McGillicuddy Serious Party of New Zealand, recently wrote at Searchnetworking.com about Don Lester, a senior network engineer with Wenatchee Valley Medical Center in Wenatchee, Washington.

Lester used the application response time and network traffic analysis modules of the NetQoS Performance Center to diagnose problems with performance of a medical records application, which “affects patient care because doctors won’t be able to do things they might normally want to do to help patients.”

The article shows our products at their best, and it would be a bit shameless of us to quote the bits we really like.

Shameless and fun!

“I popped up Reporter-Analyzer first because it's one of the quickest ways for me to look at what's going to a location," he said. "I was able to see that there was a whole bunch of traffic going to one of the locations from the workstation patching server."

Through some quick investigation, Lester was able to learn that the medical center's PC technicians were supposed to push out a patch in the middle of the night using their ability to turn on machines remotely for update. But something had gone wrong, and the PCs had never been turned on. Instead, the patching server waited until morning, when users started turning on their computers. The computers started pulling patches, which slowed down the WAN link at the remote location.

The problem at the second location was completely unrelated.

"There were no signs of anything," Lester said. "The link didn't have any significant traffic at all."

He pulled up another NetQoS tool -- SuperAgent, which analyzes TCP transaction -- and saw a high level of retransmission delay occurring at the second WAN link.

"So there was a problem with that circuit," he said. "We had to work with a third party who managed the circuit because it's not something we have a lot of eyes into. We told them to fix it. And we were able to use the same tool to tell when, in fact, they had fixed it and if it was as good as it was before the malfunction…

It kinda gives you a warm, squishy feeling in your heart, doesn’t it?

…As well as maintaining critical application performance, Lester's NetQoS tools control network costs.

"It isn't unusual for us to be negotiating a [WAN] contract based on a tier of service that is defined by the average amount of bandwidth consumed over a given period of time," he said. "There have been times when the vendor in question will inadvertently overstate our usage. When that happens, we will produce usage graphs over whatever time period is appropriate, detailing our actual usage -- and ultimately reclassify our tier level and negotiate a lower price."

Lester said a more common issue that comes up is dealing with application vendors. Often, when there is a performance problem with an application, the vendors will take a number of standard corrective actions to try to solve the problem. If none of these actions works, the application vendor will often blame the network and claim that the medical center needs more bandwidth.

"We are able to tell rather easily using NetQoS tools whether or not we really have a bandwidth issue and can then share that information in a concise graphical format," Lester said. "This not only saves us the cost of unnecessarily upgrading circuits, but it also results in better service to the end user since this re-engages the vendor. The troubleshooting escalates, and the root cause is isolated and repaired."

I think that the article illustrates one of the reasons that NetQoS focuses on performance rather than fault – that is, performance data is more valuable than fault data. You could use a quick and dirty program to check on fault and availability, but for more difficult performance problems, you need more sophisticated monitoring tools.

(I just got this idea for a comedy sketch in which you have a doctor that only checks for availability – all patients are either “alive” or “dead.”)

We contacted Don Lester for his thoughts. He said that:

“I have a lot more than two applications I worry about, but there are two that are more important than all the others. All in all though, it does detail what everyone should hope to have in their environment. Simply the ability to troubleshoot or analyze without having to guess or act on instinct or hunches. It is a lot easier to do this kind of work with solid, factual information than to sit around pinging everything and hoping you stumble onto a smoking gun.”

We just announced that NetQoS Unified Communication Monitor works with Microsoft Office Communications Server 2007 Release 2 [OCS 07 R2] this morning, and while it’s easy to get into the small details of how unified communications applications place great demands on the network, and how to handle those demands, I found myself pausing for a moment.

Where, exactly, are we going with this?

And by “we,” I don’t just mean NetQoS as a company but I mean – Us. The big Us. The human condition.

That is, unified communications applications do place more demands on the network than any other type of data that’s come before it. So, why then, do we even do it in the first place?

It’s because treating voice and video as data to be sent over the network allows us to do more with the communication-as-data than we could with the analog alternatives, even if this makes the network as a whole slightly less effective due to congestion – or if you have good performance monitoring information perhaps no less effective, but perhaps more complex. (We try to simplify the complexity as best we can, by using metrics directly from OCS 07 R2, but the necessities of a mixed communications and data network are simply more complex than the needs of a pure data network alone.)

Everything is becoming binary data, and this process is not likely to stop. To those of earlier generations, the New York Times is a newspaper; to many of the young, the New York Times is a news Web page with video and audio content; text and images being one of many offerings possible. A back-of-the-envelope calculation shows that it would be cheaper, over the course of a year’s subscription, to send every New York Times subscriber a free Kindle E-book reader – at retail prices, no less – and send the newspaper to them digitally, than it costs to print out and deliver all those physical papers to the subscribers.

It doesn’t take long to realize three things: Technology is getting cheaper, paper and distribution is getting more expensive, and the market of people who read the New York Times but will only do so if they have a physical piece of paper are dying out. The Grey Lady will become data, or there will be no Grey Lady.

Every advantage of the physical paper - portability, permanency, and simplicity, is being lost as technology becomes more portable, more permanent, and simpler. Our standards for digital technology to replace the more traditional equivalent are relatively low. Assuming it takes two and a half seconds to locate an article by flipping through the pages, any system that can serve up a Web page in less than 2500ms is an improvement. Even the sheer scale involved – that you would measure the time it would take to find an article in milliseconds rather than seconds – implies an entire quantum leap from the old way of doing things.

Those of us who work closely with the Web – bloggers, Web designers, media professionals – are aware of CSS, which removes content from layout, and RSS, which removes content from context. How far can we be from a society in which all content is completely removed from any sort of context or layout? A society where everything is abstracted? Where you could download the model of a basketball, and print it out on a 3D printer. Or even, if you wish, have the New York Times printed daily on a basketball, if you so chose…

But in that world, where everything is data, network performance suddenly becomes one of the most important things in the world. The bottlenecks once caused by the unfortunate limitations of pure physics suddenly give way to a single bottleneck – that of network performance.

Digitization is an awesome and powerful force… and while it has been mostly beneficial, I think that too often we do not recognize the power of this inexorable tide – this benevolent but gargantuan inevitability.

I don’t know if I’m ready for that world. I’m not sure I want my news to bounce.

An interesting post over at Slashdot pointed me over to a Network World story by Mitchell Ashley about how Windows 7 wouldn’t be a compelling upgrade from Windows XP. The interesting aspect is that Ashley goes on to suggest that perhaps the idea of OSes might become irrelevant if you move to thin clients connected to virtualized computers over the LAN.

The future Simon paints is one where these personal and business computing environments are virtualized onto the same computer, rather than intermingled as they are today. Businesses will deliver virtualized full OS plus apps, and stand-alone virtualized apps, to computers that users own. This maintains the security of corporate data and applications, and allows the business to viably deliver a computing environment they manage on computers they don't. Obviously this vision is in line where Citrix is going with XenServer, XenApp and their newly announced Project Independence, and given my own views about desktop and application virtualization I can see merit in a lot of Citrix's vision.

While we haven't seen much of this yet, I believe it would be wise for Microsoft to continue to improve Windows 7 as an easily virtualized OS and a platform for delivering virtualized applications. Microsoft has partially move Live Essential apps into the cloud. As they move Office and other apps online, the OS becomes thinner and thinner, less bloated with applications that entangle themselves into the registry and Windows folder of Windows 7.

You know what, I might be wrong on this – but I don’t see it happening.

This is not to say that thin clients and virtual desktops don’t have their place, but the problem with virtualizing the desktop is that offloading processing to a datacenter means, necessarily, more traffic on the LAN. Individual applications may be run remotely, sure, but operating systems – or specifically the graphical user interfaces of those operating systems – carry a lot of overheard. (If we were all using command line interfaces, the overhead would, of course, not be nearly as great.)

Additionally, companies have been moving more towards having consolidated servers connected to the end-user via the WAN – by bringing the servers closer to the datacenter, you’re also, in effect, moving the users further away. You can have virtualized desktops saturating your LAN, or virtualized servers saturating a WAN, but it would be extremely unlikely that you could have both on the same WAN.

What seems more likely is the use of virtual servers to serve up specific applications – applications that can be optimized to reduce overhead on the network. I just don’t see that happening with XP, nor Windows 7 – perhaps only the next generation – the Microsoft Cloud OS, perhaps – might be light enough to handle virtualized desktops. Then again, a computer’s what, $300 from Dell nowadays? And are you saving that much if you have to get a thin-client appliance for each user instead of buying a general purpose PC?

There have been some worthwhile attempts to do the WAN equivalent of having a cake and eating it too - a number of WAN Optimization vendors are putting in Windows services on the WAN Optimization blades themselves.  That is, one of the ways they optimize the WAN is to keep traffic off of it – and one of the ways to keep traffic off the WAN is to take care of Windows services on the branch LAN, before it even reaches the WAN.  In a way, it’s sort of the opposite of server consolidation – but since you have to run the blade for WAN optimization purposes anyway, you’re not adding additional hardware or sucking up much more power. 

This is pretty much speculation at this point – but speculation is fun, isn’t it? I’d love to hear your comments on this.

By Patrick Ancipink

So far, so good at Cisco Networkers in Barcelona this week. Despite spirits being a little tempered by the worldwide financial crisis, attendance seems to be quite good and we are noticing a radical shift in what enterprises and service providers are trying to accomplish with their networks.

One topic that’s a bit been very popular with this audience is the concern about VoIP and video quality on converged networks.  So you could say network pros are more jittery here about latency-sensitive UPD applications than they are about the macroeconomic situation.

Heh…

Moving on...

The primary concern about video has shifted from quashing recreational YouTube viewers to ensuring the network can carry video. We spoke with several different companies (with headquarters from Sweden to Qatar) that have requirements to stream video across the WAN as part of their mission. I was involved in several conversations and overheard several more where the main topic was using application-aware network management tools and techniques like IP SLA and how to determine, validate and assure QoS.

I have to say I was pleasantly surprised about the awareness of the Cisco NAM support we announced the day before yesterday. It seems like before the news even hit the wire we had several attendees asking how they could use their NAMs alongside NetQoS. There are some monster implementations of NAM out there so everybody’s happy when you can leverage the existing investment for better application response time monitoring and performance troubleshooting.

Tapas and Rioja are nothing to complain about either.

We recently praised Comcast for coming up with a solution to congestion while remaining platform and application agnostic. To recap: Comcast’s new policy is to lower the class of service on packets sent or requested for those users who are currently using more than 70% of their bandwidth over a 15 minute interval only during times of congestion. 

However, the FCC doesn’t necessarily agree – they’re asking why VoIP calls made on Comcast Internet might be choppy during times of congestion – but Comcast’s “Digital Voice” service won’t be choppy.

There are a number of issues; but ultimately, the reason why Comcast’s Digital Voice service is being treated better than other VoIP services is that the Comcast service travels on Comcast-owned pipes as far as possible before connecting to the general Internet.  Since Digital Voice traffic isn’t considered “Internet Traffic” it won’t matter when determining whether a particular user has been saturating his or her connection during times of network congestion. 

This argument may get Comcast out of trouble as far as net neutrality is concerned, but when making a voice offering distinct from that of the general internet, the FCC may rule that the service is a “telecommunications” rather than an “information” service.  That means being subject to different governmental regulations. 

Comcast isn’t the only ISP looking for ways to prioritize traffic and deal with congestion; Cox communications has announced that Internet users in Kansas and Arkansas who are using “time-sensitive” applications or services (we suspect it’s layman’s speak for “latency-sensitive” purposes like gaming, VoIP and teleconferencing) will get priority over downloading files during congestion periods. 

Though the coverage in TMCnet states that Cox “entered into the Net Neutrality arena” the solution to prioritize traffic seems sufficiently neutral to us – the prioritization is not based upon the particular application but on a class of latency sensitive applications (possibly determined at the transport layer [layer 4] rather than the application layer [layer 7]).

It will be an interesting study to see how the two different measures stack against each other; perhaps we might get some good data on how effectively the different policies tackle the same goal.

Today we just put out a press release and went live with a Web page announcing our integration of SuperAgent application response time monitoring into the Cisco Network Analysis Module (NAM). The integration combines NetQoS SuperAgent’s ability to baseline and analyze application performance across the entire network with the NAM’s high-resolution troubleshooting capabilities and data collection capabilities.

Or in short, instead of having a NAM and an external SuperAgent collector(s), you now have the ability to have both in the same box. Isn’t that swell?

The NAM monitors and analyzes network traffic, and provides Layer 2 to Layer 7 visibility into the network traffic. The benefits of combining Cisco NAM with SuperAgent are summed up by Paul Hoyle of the California Department of Transportation WAN Management team, which has already tested the combination. Hoyle said:

“We will be able to combine the data from our multiple NAMs with our other SuperAgent collection sources and view it all in the NetQoS management console, which will help us better understand how applications are performing across our organization and quickly drill down to any NAM for efficient troubleshooting. Plus we get the benefit of monitoring more applications without having to deploy additional SuperAgent hardware.”

As a tag-team, Cisco NAM provides visibility into network and application performance to help ensure the consistent and efficient delivery of applications and services. SuperAgent then takes that information, and delivers an enterprise-wide view of performance, volume, and availability metrics across all of the NAMs (plus SuperAgent’s own collectors) in the network, as well as the ability to drill into each NAM user interface for high-resolution diagnostic reporting. SuperAgent also automatically investigates the cause of problems in a way that augments the NAM diagnostics. For example, SuperAgent can immediately launch a trace route investigation when network latency increases above a normal baseline.

By Steve Harriman

Last Tuesday, Riverbed, known primarily for Steelhead, its WAN optimization controller (WOC), acquired Mazu, known primarily for its network behavior analysis detection (NBAD) tool Mazu Profiler. Riverbed said that they’re planning to integrate Mazu’s technology into their own products.  Similarly, Blue Coat, another WAN Optimization vendor, announced earlier today that they are going to partner with Lancope, another NBAD vendor, for much the same reason.

Before the acquisition, both Mazu and Lancope had been retooling their messaging – moving from a security focus to a more of a network performance monitoring focus in an attempt to appeal to a much broader market. In the long term, it’s likely that NBAD is unsustainable as a standalone market – but could be part of the broader set of network performance management disciplines. It appears that the WAN optimization vendors agree and are becoming interested in expanding their performance management capabilities. Indeed, Blue Coat already demonstrated this with its 2008 acquisition of Packeteer. In hindsight, it’s a little strange to see network performance monitoring and network behavior analysis as two separate fields. 

However, these flow-based NBAD technologies should not be confused with the Cisco-NetQoS technology in Cisco’s WAN Optimization offering--WAAS. In July of 2007, Cisco and NetQoS jointly developed instrumentation for WAAS devices that feeds key performance data to our application response time monitoring product SuperAgent.  SuperAgent was designed from day one to track application-by-application, subnet by subnet, the end-to-end performance of applications running over WANs, and merely had to be adapted to the optimized WAN environment. The SuperAgent-WAAS integration restores visibility into optimized WAN links which create unique visibility problems by breaking the TCP stream up into three separate streams. Without instrumentation in the WAN Optimization Controllers (WOC), you need to have monitoring equipment on both ends of the optimized connection. That gets expensive, so it makes sense to have the monitoring software embedded (at no additional cost) in the WAN optimization equipment. 

Without this tight integration, you can still derive a lot of performance-related information from the WOCs as long as they export standard network flow datagrams, notably NetFlow or IPFIX. This data provides visibility into traffic composition across the optimized link so you can see what effects the WOCs are having in reducing traffic. However, it doesn’t tell you anything about the end-to-end response times so you can’t tell if they are better or not (which is severely disappointing if that’s why you bought the WOCs in the first place). NetQoS customers use our ReporterAnalyzer product to monitor NetFlow/IPFIX exports from these WOCs, including those from Cisco, Riverbed and Blue Coat.

It’s not just enough to optimize a WAN connection and hope for the best. If your WOCs–from whatever vendor you choose—are to be effective, they should be monitored. In fact, it’s really smart to monitor your links before you deploy WAN optimization gear so you know which remote sites are the best candidates and to give you baseline performance statistics. Performance monitoring not only helps you measure the performance improvements you’re getting, it helps you solve problems faster.

Given this, it may seem strange that Riverbed would be interested in NBAD technology which gives it NetFlow visibility but not latency visibility across the three segments of the optimized WAN link. We should assume that Riverbed will use its newly-acquired technology for more general purpose monitoring and expand its capabilities over time. Interestingly, Blue Coat’s roots are in the security space and it’s quite likely that Riverbed’s acquisition was, at least in part, intended to bolster its own security-related offerings.

NetQoS has offered NBAD capabilities in the NetQoS Performance Center since February of 2008.  

[In the interests of full disclosure: Network Performance Daily is the “house organ” company blog of NetQoS, and is competitive in the behavior analysis space to Mazu and Lancope. –ed.]

Steve Harriman is VP of Marketing at NetQoS.

Chandra Hosek, Ben Erwin, and Andrea Stout contributed to the research of this post.

The world is a small place – and getting smaller. Nobody knows this more than the people who work in networking and IT. We’re the people who are trying to connect people and bring them together. (Well, us and various diplomatic corps, but it’s a totally different type of bringing people together.)

This is all leading up to our announcement that NetQoS has worked out a distribution deal for the NetQoS Performance Center in Malaysia with the Kuala Lumpur-based Extol. This includes  SuperAgent, Gigastor, ReporterAnalyzer, NetVoyant, and Unified Communications Monitor.

Justin Tan, the CEO of Extol had this to say about it:

“The NetQoS Performance Center consists of award-winning, proven management solutions that will complement Extol’s offerings by helping our clients manage the performance of their devices, links and applications in addition to their risk and threat management. NetQoS products are reliable, easy to deploy, and scale to large networks so that our clients can monitor and improve their network and application performance.”

We’d say “aw shucks, you shouldn’t have,” but then we remembered that Extol is doing sales and marketing for us in the region, so…

Anyway, the sentiment is appreciated.

Extol is well known in the region as a security solutions provider, focusing on areas such as fraud detection, forensics and incident response, anti-virus, security systems management, and secured enterprise applications. Being able to complement that background with our network monitoring suite is a bold, logical step.

In the meantime, our technical representative in the Asia-Pacific region, Wilson Leong, presented a plaque recognizing Extol as a channel partner to Extol CEO Justin Tan at the launch of Extol's new offices. He took some pictures that we’re happy to share with you below.