Anomaly Detector, our network behavior analysis tool, discovers something horrible. See the video below for details.

I first heard about this pressing enterprise information technology concern when a friend directed me to MyTractorForum.com.

Now, I know more people with Segways than tractors. But the story involved the Kingsbury electrical substation less than five miles from my condo, and it involved someone who apparently broke through the fences in order to dig up the copper grounding wire of the electrical substation. He was ultimately - in a "BZZZZZZAP!" way - unsuccessful.

He is currently in "extremely critical condition." And I'm a monster for laughing, but let's face it, this is stuff that is supposed to be confined to the realm of Wile E. Coyote cartoons.

Speaking of Wile E. Coyote cartoons, it made me think of the Road Runner - or Road Runner cable, in this case. See, the apparent thief was stealing copper wire because copper prices are sky high, and this brings me to two interesting points: First, it's not inconceivable that someone might dig out the copper wires in your company, raising havoc with the physical layer of your network performance. Second, if copper prices are high enough to risk electrocution for, it's high enough that companies might want to start thinking about transitioning away from copper-based technology.

It is because human stupidity is particularly destructive that this is something to watch out for. Any large electrical equipment - like, say, a data center's power plant - will have copper in it, either as grounding wires, or as part of the construction of the machine. Or, let's take Cat-6 cable: four twisted pairs of 24 gauge copper wires, running throughout the infrastructure. Sure, it would be a repetitive and tedious task to strip out the cable, a task that requires the inhuman patience and obsessiveness of, oh, say, a habitual methamphetamine user, or "tweaker."

The major concern isn't that a thief will "get away with your stuff." Repairing and replacing copper cable, even with the high prices involved, are not likely to be significant expenses for companies. However, the costs of repairing the auxiliary damage to equipment that can be done in a theft attempt, and the opportunity costs from waiting for service to be safely restored, are likely to be significant. The Kingsbury station man who did his impression of a bug zapper also cut off power to 7,300 nearby homes.

It's strange because while we worry about viruses and worms, hackers trying to get at valuable data and cause disruption; people often don't think about the physical layer of their networks.

Of course, you could just put some sort of deterrent up to prevent people from stealing copper. Perhaps
some sort of electrified fence, because you'd have to be pretty dumb to… oh.

Which brings me to the next point: with copper prices sky-high, perhaps it's time for new technologies - specifically fiber optics - to start becoming even more widely used. Yes, fiber is expensive and difficult; better suited to long-haul connections, but it will become less expensive and difficult with increased adoption; and copper is inexpensive and simple, though it becomes more expensive and difficult as time goes on.

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.

by Brian Boyko
Editor, Network Performance Daily

If this blog post seems a little… more off kilter than usual, it may have something to do with the fact that I'm totally wiped.

See, I bought an IKEA bed and assembled it by myself last night. Now, I won't say that it wasn't time-consuming, but apart from the part where I had to run to WalMart at 1:30 in the morning for an bradawl*, the directions were simple and easy to understand with the little mute Swedish IKEA guy showing me what to do and what not to do, without having to use a single English word, and I was able to get the whole thing up and assembled despite increased eye-blurriness, finger clumsiness, and yawn, er… yawniness as the night went on.

Now, I know that network engineers and administrators are no strangers to no-sleep late hours and even to middle-of-the-night trips to the data center - something goes wrong with the server, you get woken up by your pager, you try to fix it from home, but you can't, and you have to run down to the data center, and end up staring at command lines until six in the morning, at which point you start to hear spooky voices in the exhaust fans of the rack-mounted computers. (It sounds something like: "Brrrrrrrrnosleepforyourrrrrrrrrrr")

When these things happen, there are two things that make a world of difference: simple, easy-to-understand and use tools, and heavily caffeinated beverages.

I like Mountain Dew, and those mocha/expressos with chips in them from Starbucks. Hold on. I'm going to get one before I crash. I'll be right back.

Still there? Anyway, good UI design can make or break a network engineer's sanity in those wee morning hours. As networks become more complex, network engineers need tools that are easy to use. Your brain does not run at maximum capacity in that deprived state and you need all the brain cells you can muster to think about the networking stuff that you're good at, not to have to remember a whole bunch of arcane commands and directions to get to the information you need.

"Visibility into core metrics" doesn't just mean that the core metrics are available if you can find them. Visibility - true visibility - means that there's nothing obscuring the information you need when you need it. That's why UI design is extremely important for networking tools.

*yeah, yeah, I know, but there are times in your life when it's 1:30 a.m. and you desperately need a bradawl.

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.

CIA Plan #328 to remove Castro from power in Cuba has succeeded. This plan, also known as "wait until El Presidente gets old and retires," now suggests that there will be vast geopolitical changes.

However, while Castro may be retiring, the communist regime he's supported for nearly half a century isn't going away, and whoever wins the elections in Cuba, the policies vis-à-vis the U.S. probably won't change that much until and unless the U.S. foreign policy towards Cuba drastically changes after the next U.S. election.

Which is a shame, really, because when old hardware (I have no problem calling Castro "old hardware,") is too troublesome to maintain than to replace, it's usually a good time to re-evaluate the way that your company, or, in some cases, your tropical island nation, does business.

Now, whether Castro is retiring because of his natural health, or because the CIA slipped him a cigar with a really, really slow acting poison back in 1963, it doesn't matter. The point is that we are so used to the way things are, we often don't pause to consider what could be. We don't understand the true cost of maintaining legacy hardware versus trying the new, and don't give much thought to better alternatives if "things are working well enough."

IT professionals have been thwarted many times by using legacy management tools that are outmoded, increasingly and annoyingly cumbersome to maintain and administer, or no longer deliver the value for which they were acquired. Beyond the obvious maintenance and license costs, there are also the opportunity costs related to speed, quality, scalability and efficiency. When you combine high maintenance costs with opportunity costs, the financial penalty for the status quo begins to add up.

Now, no one should advocate tossing out a product or technology just because it's a little long in the tooth- in fact, long, huge, revolutionary solutions when small fixes are the most efficient solution can be a serious problem that takes time and energy away from IT. But, there is nothing wrong with taking time to assess the situation and ask whether we're better served by what is or what could be.

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.