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.