Verizon and NBC are working on serving up TV shows to home computers. The problem is, high definition video, (and I've done some HD video work for the Web - shameless plug), takes a whole mess of bandwidth.

Now, the obvious solution for NBC would be to move to some sort of peer-to-peer distribution system, right? I mean, it works for Linux distros.

The problem is that a normal peer-to-peer connection doesn't distinguish between the cheap local links - that is, links on the same ISP, in roughly the same geographic area - from the expensive remote links. So while P2P provides a more cost effective solution, it doesn't provide the most cost-effective solution for the ISP.

A third party, Pando, has developed a P2P system for pre-authorized, pre-approved content, and has come up with a way to force peer to peer connections to look for local nodes first. This increase the efficiency of the system, lowers the cost, and generally increases the performance of the streaming/downloading video.

This is exactly the type of thing we talk about when we say that how the application is coded can have a huge impact on the application performance over the WAN. Sometimes instead of needing more bandwidth, you need to find a way to make the apps work more efficiently.

In this case, decentralized P2P systems developed after the destruction of Napster. Though they were much less likely to get shut down by the RIAA, they were also much less efficient. This dominated development of P2P applications for years. But for offering only pre-authorized content, a centralized system - especially one that takes advantage of the structure of the physical network, makes a certain bit of sense.

NBC will be offering Verizon customers their shows via Pando's P2P service - which they're calling P4P, later this year. The name is a logical outgrowth, P2P, or "peer to peer," versus P4P, or "peer for peer." P3P was disregarded because it sounded too much like PCP. And if a kid with a lisp goes around school saying: "I downloaded the latesth Methallica album on P3P" and a teacher hears: "I downloaded the latest Metallica album on PCP," well, that's just not going to be a story that ends well, now, is it?

There's only one problem with Pando's plan: Each ISP will have to give up information about its subscribers in order to participate - that is, the Pando platform requires knowing which nodes are "local" and which nodes are "remote" in order to optimize for the local connections:

For other ISPs to reap the benefits Verizon did in the test, they too would have to share information about their networks with file-sharing companies, and that they normally keep that information close to their chests.

''That's one of the objectives we have to solve -- how are we going to consolidate this data and distribute it?'' Pasko said, adding that the result of the test gives ISPs plenty of incentive to collaborate.

(Okay, maybe there's two problems: No offense to NBC, but when your biggest hit is a veritable case study in game theory… you need some new shows.)

June 16, 2007, Network World:

"We're telling IT executives to not support it because Apple has no intentions of supporting (iPhone use in) the enterprise," Gartner analyst Ken Dulaney says. "This is basically a cellular iPod with some other capabilities and it's important that it be recognized as such."

March 6, 2008, Network World:

During a media conference at its San Francisco headquarters today, Apple unwrapped a host of new features that are designed to make the iPhone more attractive to corporate users.

Six months is a long time in the tech world…

We've warned that eventually the iPhone would be appearing on corporate networks and that the new (at that time) devices would introduce vulnerabilities into the corporate network and take additional resources. What we weren't counting on was Apple making overtures to enterprise networking - we had assumed that, much like the original iPhone was hacked to run on multiple carriers, that those who wanted to use the iPhone for enterprise applications would have to provide their own, messy, stop-gap solutions.

Back in January of 2007, when the iPhone was first announced, we wrote:

"That's another question - will this device have VPN support so that traveling employees can get the information they need while on the road? And if they do - how do you secure the data? The iPhone, like all small devices, is easy to lose, and easy to steal. That makes it vulnerable to illicit access. Does the iPhone have cryptographic abilities to make sure data stays safe?"

Well, apparently, Apple didn't take that as a rhetorical question because the fruit-based tech company is going to support Cisco IPsec VPN in the next iPhone update - the same one that will bring secure Exchange support as well as the possibility of an "iTunes Store for iPhone apps" - current Apple plans are to allow third party development but that Apple would have the final say on whether or not the applications could run on the iPhone. (Of course, clever hackers have already found a way around that.)

At any rate, the iPhone now seems to be competing directly with the Blackberry, which is good in the sense that competition in technical markets lead to innovation, and companies will have to expect new types of devices using different types of traffic, which - well, isn't bad, but which can be frustrating, absent a network device monitor.

Personally, I'm a bit confused by Apple's insistence to cripple the iPhone into only running "acceptable" applications on the iPhone, as A) it's clear that people are going to use it the way they like anyway, and B) if Apple took the same attitudes with their Macintosh/OSX general purpose computers, some of the best Mac apps (Quicksilver, Colloquy, Transmission, Burn,) simply wouldn't exist. Perhaps this increases the security of the device but at the obvious cost of utility.

It's just rhetorical, and I'd love to get some comments on this, but is the tradeoff between security and utility a false one? I'm not sure - havening not worked much in the security side of technology - but it seems to me that if the iPhone can be hacked to make it more useful, it can also be hacked to make it malicious, and so the choice is not between security and utility, but rather between a lack of security with utility, or a lack of security without utility. Hmm… maybe I should ponder this more.

The Wall Street Journal has a column by Amit Basu and Chip Jarnagin about how most companies are failing to recognize the potential of IT, and they list a number of reasons why.

First, Basu and Jarnagin say, the business often sees IT as a basic utility, like plumbing or phone service. This is compounded by the current trend towards SaaS; in which prominent authors like Nick Carr are actually sincerely arguing that IT is indeed a basic utility, and that "IT doesn't matter." We disagreed with that argument on the basis that those companies that use unique IT resources and talent effectively will outperform those companies who do not, but agreed with the general trends that Carr pointed out. The problem that many overlook is that IT as a utility and IT as an innovator are not mutually exclusive propositions. (Remember when your cable company just provided TV?)

Additionally, Basu and Jarnagin argue that there is an effective glass wall isolating IT within the company, and there are five reasons for this wall separating IT and the rest of the business.

"Mind-set differences between management staff and IT staff, language differences, social influences, flaws in IT governance (defined as the specification and control of IT decision rights), and the difficulty of managing rapidly changing technology."

The first case, of mindset differences between IT teams and business leaders is one of abstract vs. logical thinking. IT teams often deal in binary logic; something works or it does not, something is better or it is not. There is a right way, a wrong way, and sometimes a best way, to do things. Business leadership often deals in the grey areas, what ifs, and sometimes illogical intuition.

To oversimplify, IT thinks in the terms of the math class - there is a right and wrong answer. Management is liberal arts - arguments should be well formed but there's no one right way to get to the answer. For all the jokes between management and IT working on totally different wavelengths, there is an absolute truth to this.

Also, as Basu and Jarnagin point out, both business and IT use incomprehensible languages filled with acronyms and specialized terms. I know most of you are familiar with "VoIP," "packet priority," and "ITIL" but to a business manager, they're as alien as "EBITDA," "commodity value," and "ISPL" are to a network engineer.

(A digression: When I first started working at this position, I came from an academic background. It confused me to no end that when the marketing people were talking about "the pipe" and the networking people were talking about "the pipe" they meant two entirely different things.)

There are other, social, factors mentioned in the article as well, but the end result is that business doesn't want to deal with IT, doesn't care about IT, and doesn't understand how IT helps their business. And yet, IT is still crucial to meeting business goals.

We've talked many times about the need for better IT communication, and better understanding of business needs in IT. Mostly, we agree with Basu and Jarnagin's assessments of the situation, and really do recommend that you read the article - and perhaps forward it to your manager.

This is where ITIL can help out considerably. One of the major improvements in ITIL v3 from v2 is the shift from business alignment to business integration, which requires IT to adopt business terms and to create, measure and communicate IT value in financial terms whenever possible.

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.

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.

Last Wednesday, Feb. 13, 2007, Carolyn Duffy Marsan at NetworkWorld wrote, "The American Registry for Internet Numbers plans to post proposed changes to its IPv4 address space transfer policy on its Web site this week."

According to NetworkWorld, that would allow ISPs to transfer IPv4 address registrations; and thus fuels speculation that IPv4 addresses would become "tradable goods." As many IPv4 addresses were assigned before the current popularity of the Internet was seen, this benefits those large corporations, universities, and government institutions that were allocated large blocks of IP addresses.

In fact, the next day, Feb. 14, 2007, NetworkWorld ran an interview with Internet Assigned Names and Numbers (IANA) general manager David Conrad, in which he basically confirmed that there would likely be a market:

"I can't actually imagine there not being a market. The market will either be black or white. If black, it will have a negative impact on the ability of ARIN to maintain accurate databases, such as, Whois. If white, ARIN (and the other Regional Internet Registries) will undoubtedly get dragged into politics related to fairness, particularly with respect to the developing world."

Indeed, if adopted, this would be a major reversal of policies by ARIN, [PDF] which made this statement in a press release last October:

"There are, however, those who propose that the democratically established governance principles now be abandoned, to create a market in IP addresses. A market that abandons these existing, consensus-driven core values would encourage speculators to take advantage of the upcoming time of relative scarcity of IPv4 addresses to profit from less foresightful users' remaining need.

The purpose of this memorandum is to assure the community that the democratic principles of Internet governance will be adhered to by ARIN, the Regional Internet Registry serving Canada, many Caribbean and North Atlantic islands, and the United States.(7) The resource-allocation policy under which ARIN operates has been produced through an open, transparent, and democratic process over more than a decade. ARIN is fully dedicated to preserving universal access and stable functionality of the Internet, and our policies do not encourage profit-driven speculation in the Internet addresses."

The humor value in watching the gullible bid for 172.0.0.1 on E-bay aside, I find it difficult to understand how a market for IP addresses - black or white - would sustain itself. Yes, IPv4 addresses are scarce - but it is only an artificial scarcity.

IPv4 prices can only rise so high, because if the cost of buying IPv4 addresses becomes higher than the cost of moving to an IPv6 based infrastructure, companies will move to IPv6. And, of course, the more companies that do move to IPv6, the more the intrinsic value of IPv6 versus the intrinsic value of IPv4.

Even before IPv4 addresses and IPv6 upgrades hit a break-even point, it may be a smarter move for businesses to go to IPv6 directly instead of having to pay twice - once for an IPv4 address at its peak, and again down the road to move to IPv6 after it becomes the new de facto standard. Eventually, IPv6 addresses will have more real utility value than the IPv4 address. Those speculators left holding onto IPv4 addresses for too long will find their worth had dried up quickly. Either way, it's unlikely that a company that buys an IPv4 address will be able to make a profit reselling it except as speculation. That doesn't sound like a very stable market.

The speculation about who will move to IPv6 and when really doesn't make a big difference. Yes, we're probably going to run out of IPv4 addresses in a couple years, but there is already an established infrastructure to replace it. When companies are forced to move to IPv6, they will move to IPv6, and it looks likely that, one way or another, companies will be forced to move to IPv6.

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.

In NetQoS's resource room, we've got a free Web-based app called the NetQoS Network Estimation Tools (or "latency calculator" for short) that allows you to calculate the theoretical latency of network connections under a number of different scenarios.

The NetQoS Network Estimation Tools, a.k.a. latency calculator

Allow me to clarify: A number of different plausible scenarios. Like, for example, if you knew that there was a 5ms router latency, a 20ms server latency, and a link distance of 100 miles, you would be able to get the overall theoretical latency of that connection, whether it's point-to-point or frame relay. However, it will not give you the latency involved in IP over Avian Carrier connection. Plausible scenarios only.

In addition to the main latency calculator, there are several sub-tools, such as an Ethernet packets per second calculator, a link speed calculator (with packets per second and packet size as inputs), a multicast calculator that will give you the Multicast Low Order and a MAC address, a HEX to decimal converter, and other tools useful for the network engineers at their desks and in the field.

The calculator was invented as a teaching tool by Bill Alderson, who has been diagnosing problems in large-scale networks for 25 years. We asked him what some of the uses for the calculator were out in the field.

Bill Alderson: You can use it to calculate how long it would take to do an FTP transfer from a 400 MB file to… whatever. So it's pretty easy and simple, it does take a little bit of instruction, but the latency calculator counts the number of round trips that are required and you can make the size whatever you'd like. Instead of having a packet size with a 1500 or an 8000 byte MTU maximum, you can simply crank in a 450GB file, and it'll tell you how long it'll take to serialize that file across the links you have selected.

You can put in all of the various entry points which are drop-downs of Ethernet, drop-downs of T1s, sub-T1 speeds, and you can just pick those in there, and then you can change all the sizes and determine, theoretically, how long a transaction should take.

Let's say that you were in Dallas, and you wanted to do a transaction with a server in San Francisco (or Japan or what have you). All you have to from your desktop is to go and ping your destination and find out what your latency is. Then you can make sure that the latency you put in is the same the calculator has. We don't express that latency necessarily in exacting numbers, but we have some general rules the industry has used. I like to teach people from a standpoint of being able to do the math in their head eventually after they've used the calculator 10 or 12 times, they can do this math in their times.

So rather than doing this an exact 186,000 m/s speed of light transaction, I broke it down into very simple things like 100 miles is about 1ms of latency. That way, not only can you use the calculator, which will also calculate serialization, but most of the latency calculations are things that are changing all the time - not exact numbers. The 1ms per 100 miles or 1.5 seconds for 100 miles of frame relay - it works out. It's very very close, especially for the type of things that people want to do.

You try and break down very complex things into very simple things so that the average man or even the non-average man who doesn't calculate those things very often can have an anchor to information that helps them begin to do it in their heads so it's second nature when you do a ping from your desk. If you do go in and do everything exactly, down to the nanosecond, the largest part of the audience's eyes glaze over, and they're completely lost.

When you see when something's 2000 miles away and comes back in 40ms, you see that you're very close to the theoretical. But if it comes back at 92ms, you're going to scratch your head and say, "That's too far away from theory. I'd better do an investigation and analysis to find out why it's so far away from the theoretical." We're trying to give the average man the ability to calculate quickly and see the many outcomes of many different examples, so he can commit these things to memory eventually.

If you have a lot of complex things, you can crank it into the calculator, and people love it. We built it for a learning tool, but absolutely, I've used it in reports and helped people understand. That's what we're looking for: Take theoretical numbers that are very close, and help people simplify those so they can get to the answers and then learn those things so that they eventually don't have to go to the calculator.

Let us know what you think of the latency calculator in our comments section below.

The Aberdeen Group, a provider of business research services surveyed 205 organizations last month to identify best practices for enterprise network visibility initiatives and controls. They called the report "The Real Value of Network Visibility."

In the interests of full disclosure, it should be said that NetQoS co-sponsored the study but we did so only after the survey was conducted and the analysis complete. That said, though, the study pretty much validates our entire "performance first" approach towards network and application performance management.

What the Aberdeen Group suggests is a PACE model (Pressures, Actions, Capabilities, and Enablers) to achieve corporate goals. The idea is that businesses are pressured to be responsible to customer needs, and the actions that are effective are to establish a proactive control of the network. In order to do this, you need to be capable of defining your escalation pathways for network performance issues, having normal networking performance baselines, understand interdependencies between applications on the network, be able to segment round-trip application response times into delays caused by the server, the network, and the application, and finally, have a centralized point for looking at the network performance data.

Frequent readers of this blog will no doubt notice that this is the point where I usually mention that NetQoS makes some of the products which enable those capabilities. The Aberdeen Group reports that these "enablers" are network performance monitoring through a Web interface, tools for remote analysis and troubleshooting of network performance, tools for creating custom profiles for monitoring groups of network hardware, a unified network performance and security platform, tools for Netflow data analysis, and a lab environment to simulate network performance.

There are some other gems in there to be found. The survey results showed that that top 20% of performance scorers:

• Were the most likely to have the capabilities and enablers mentioned under the PACE model.
• Were spending less time on troubleshooting network performance and application performance, managing changes to network design, or enforcing network usage policies.
• Were much more likely to have merged application and network management into a single job role, and more likely to merge the application, network, and systems management teams into a single organizational unit.
• Were able to fix problems faster and less likely to rely on calls to the help desk for determining network problems.

What do you think about the Aberdeen Group's report? Feel free to leave a comment below.

It's interesting that we're coming out with an announcement about our support for Cisco Application Control Engine modules and appliances today, considering it's the same day when Juniper announced that it's not going to continue their DX application acceleration offerings. Juniper made the decision, because, according to Network World, "[Juniper] regards it as insufficiently distinguishable from competitors' devices."

Application accelerators and application delivery controllers can indeed be hard to differentiate. As one poster on Fark (and I have no idea how it ended up on Fark) put it, "The load-balancer market is starting to commoditize. This is not unlike the HTTP cache market about ten years back."

We just put out a press release with details about our support for the Cisco ACE application delivery controller. The NetQoS Performance Center and its application response time, network traffic analysis, and device performance modules are available today, integrated with Cisco ACE - a module to Cisco's CAT6500 switch and 7600 series router which provides load balancing and content switching, focusing on acceleration, security, and availability.

And it's particularly important because one of the reasons that this partnership developed was because players in this market, including Cisco, are looking for ways to differentiate their offerings.

One of those ways is being able to quantify the performance gains of the solution - with NetQoS Performance Center integration, network engineers and sysadmins can tell exactly what benefit they got for their investment in the hardware. Being able to justify your budget easily and quickly is a major selling point, and while there hasn't been a lot of focus on using response times to measure the effectiveness of load balancers, it seems a logical next step, considering we've already worked with Cisco before to provide this functionality in Cisco WAAS WAN Optimization devices.

Often, network engineers are forced to rely on CPU utilization, memory utilization, and disk usage as measurement. However, in order to really get an idea of how the application is performing for the end user, network engineers need to baseline and track server response time and application performance. In order to continue to provide good performance for the end-users, it's important to get alerts when deviations from normal performance occur and automatically investigate the source of performance issues. Combining response time metrics, historical SNMP data, and NetFlow traffic analysis is a very powerful combination.

Now, I can't tell you that there aren't perhaps other ways to differentiate your offerings. If I had a solid but unremarkable application-delivery controller and I was trying to compete with the Cisco ACE/NetQoS Performance Center integration, I could probably… paint it pink or something. You know, so that it stands out in the data center, so that people looking around will say: "Hey, what's that pink box?" Would spread word of mouth, maybe.

Or I could give away beer from a microbrewery with every purchase. I know a guy named Orf who has his own brewery. He's a good guy.

Wait! I've got it! every fifth application delivery controller is filled with delicious candy! Mmm, Candy…

What would make you choose one application accelerator over another? Please leave a comment if you'd like to chat about this. Or want candy. Mmm, Candy.