by Brian Boyko
Editor, Network Performance Daily

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

by Brian Boyko
Editor, Network Performance Daily

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

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

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

One reason, perhaps, why Microsoft might want Yahoo!

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

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

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

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

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

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

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

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

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

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

Things have gotten slower for many Web users making international communications because of three (or four) undersea cables recently cut. This is especially true for those in the middle or near east, but as the traffic normally reserved for the lines that were cut is now being routed over alternate cables, everyone's traffic is a little affected.

However, for most users, the Internet is merely slower than usual. Not to make light of anyone's current pain, but it is a reminder of the triumph of computer science and computer engineering that is TCP/IP. TCP IP was designed to route around this very type of damage to deliver accurate messages.

Depending on what news reports and analysis you read, there may have been three undersea cables cut, or four undersea cables cut, and these cables were cut over a short period of time by independent, dumb decisions by civilian ships located hundreds of miles apart to drag their anchors along the bottom of the sea to cut through cables armored with steel and polyethylene. However, the AFP news service is reporting that the Egyptian government saw no ships in the area for the 12 hour periods before and after the cable was cut.

An improbable coincidence combined with contradictory evidence? That's breeding ground for conspiracy theory.

This is either an amazing, "win-the-lottery-twice" type of coincidence combined with general widespread confusion, or some sort of deliberate damage. Some on the Internet are suggesting that these lines were cut, possibly, maybe, crazily, as a precursor to a U.S. invasion of Iran.

The "Iran invasion" speculation is fueled by the fact that the router that Internettrafficreport.com uses to measure the amount of traffic coming into and out of Iran is showing a 100% packet loss. As theories go, that's a bit concerning, but that's just one router, and as blog "Cryptogon" points out, other Iranian domain names are still serving up Web pages.

Of course, this panic is caused by U.S. rhetoric regarding Iran. Many online commentators, frightened of the possibility of an expansion of the Iraq war, have taken these outages as fear that the "other shoe is about to drop."

Network Performance Daily, as the vendor blog of NetQoS, isn't in a position to make an editorial statement about war or policies from a U.S. foreign policy angle. But that said, we can tell you that there has never been a war that has improved network performance. While there are many advances in communications technology that have been made as a result of dual-use technology defense spending - TCP/IP among them - the actual act of waging war destroys communications infrastructure. In fact, as far back as electronic communication has existed, destroying the ability of the enemy to communicate effectively was seen as a tactical advantage. Indeed, telegraph poles and the rail lines which brought mail through when the telegraphs weren't working, were targets back during the American Civil War.

Even when this destruction isn't intentional, bombs - even the smartest of them - are indiscriminate. As we see with the Iraq war, delivering even basic electricity when things are frequently blowing up is a challenge.

At any rate, the why isn't quite as important as the fact that the cables are currently disconnected and it will at least take a week or two to get them repaired. In the meantime, now might be a good time to monitor carefully the performance of your global network links to adjust to this new turn of events.

Do you know what's going on out there? If you do, please send us a comment because we have no clue whatsoever.

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.

Editorial by Brian Boyko
Editor, Network Performance Daily

Ars Technica reported that a memo claiming that Time Warner was going to roll out a "pay-as-you-go" metered scheme for Internet access, rather than today's subscription-based unlimited bandwidth access plans was leaked to BroadbandReports.com. That memo, which since has been removed, claimed that Time Warner was going to try metered/limited access on a trial basis in Beaumont, Texas, and Time Warner representatives have confirmed this plan with Reuters.

As Ars Technica pointed out, Comcast has tried using bandwidth caps and traffic shaping to curb Internet usage among the customers that pay Comcast for Internet access. Comcast, however, has run into trouble because it has not revealed those policies to Comcast's customers. Time Warner will supposedly give customers online tools to monitor bandwidth usage.

Of course, it would be the best solution to increase the capability of the network - ISPs have to play by different rules than corporate networks as they are common carriers. But we don't know whether it is economically feasible for Time Warner's cable division to remain profitable while increasing the bandwidth, and if an unlimited-access plan is not feasible, a pay-as-you-go plan seems at first to be the fairest of the alternatives.

That said, there's something a little, well, strange about this, because the Internet is not a big truck that you just dump something on. It's a series of tubes.

Solving The Wrong Problem

That is, all Internet connections are merely the transfer of little positively and negatively charged electrical bits which stream down the wire. The limitations are not in the availability of the resource but in the capacity of distribution. We are not, in other words, "running out of bandwidth" like we run out of oil, run out of water, or run out of diapers.

What is limited is the capacity of the "pipe." To strain a metaphor, you could push Lake Michigan through a coffee stirring straw, but it would take a very, very long time.

Any pay-as-you-go plan has a fatal flaw - it doesn't make a whole lot of sense to bill people for the data they are downloading because data is not the limited resource!

What is limited is the capacity of the ISP's infrastructure at any particular moment in time, so it would be saner to limit the usage of the pipeline at a particular time. Perhaps to even out the usage of bandwidth, the ISP could provide different speeds for peak and off-peak usage times. Those unhappy with the slow speeds at peak times could pay a premium for a greater share of the pipe.

But wait a minute! ISPs already do this - I know that my Internet connection at home is capped at a certain speed. In fact I could get a faster speed simply by asking for it and paying a premium - no delay nor needed infrastructure upgrades. Just cash.

So the move to a pay-as-you-go plan seems, to be at best a case of solving the wrong problem, and at worst a case of "double dipping" by making people pay for data and bandwidth. (If there are network slowdowns, charging people per-gigabyte won't help much if people are still downloading that gigabyte at the same time of the day, after all.)

Your Experiences May Differ

Unfortunately, I've been on the receiving ends of one of these plans. Recently I was in New Zealand filming a movie about electoral reform. Bland stuff. While I was there, I was planning to upload film to the Internet - sort of a production blog. But I found that I couldn't - the ISP there, New Zealand Telecom, had placed my flatmates and myself on a pay-as-you-go program with a cap of only one gigabyte, and they would not increase the cap until the next billing period, which would have been after I left the country.

One gigabyte. Anything over that amount was downloaded at speeds that I hadn't seen since I bought my last 56.6k modem. That meant that even doing things like normal Web browsing was a particularly hard chore. Uploading film to YouTube was right out. I was even hoping to get some extra work done for Network Performance Daily during that time but found that I simply did not have the ability to do so. I was, in a word, ticked off and frustrated. It certainly made it quite a bit harder for me to use the network - I ended up getting a lot of iced mochas at the local Internet café, as patronage was a prerequisite for Internet service.

Now, I have no idea if Time Warner plans anything like New Zealand Telecom, and Time Warner has more competition - even in Beaumont, TX - than New Zealand Telecom did in Wellington. That may force them to abandon this plan if they find customers cancelling accounts and leaving for competitors.

It is rather important to notice that the last mainstream successful service that charged you based on how much you used it was 1996's AOL.

I've never been to Japan, France, or Korea but I'm told that all of these countries have broadband available at much greater speed, without having to worry about pay-as-you-go plans. So the question is not whether unlimited broadband is technically feasible as more people use broadband, the question is whether companies are willing to make the infrastructure investments necessary. And considering that there will be more competition, not less, as new technologies (like FIOS and WiMax) become available, investing in infrastructure rather than limiting customers seems to be the smarter move in the long term.

But let's say that this plan is a success in Beaumont, and catches on. What's the upshot for enterprise networking?

You Think You Have A Recreational Network Use Problem Now…

If people come to expect that every piece of data that goes through their network is going to cost them extra money, that may mean that all the large data that they were once downloading at home now ends up getting downloaded to the corporate network and taken home via flash drives. In addition to the spike in traffic use, there are also issues with copyright infringement liability, computer security (with flash drives from home possibly containing malware - not to mention that people will probably swap flash drives within the company, spreading infections,) and people looking for large files to download before they go home instead of doing work.

Now, in many ways, the problem with limited bandwidth availability from an ISP may seem similar to limited bandwidth availability on a corporate WAN. But a business has many more options for dealing with slow networks than an ISP does. Businesses can check their application performance and if necessary recode them (many legacy apps designed for a LAN are too "chatty" for the WAN.) They can set QoS policies to make sure certain types of traffic from certain types of applications get priority. Traffic can be rescheduled so that it goes through the system during off-peak times.

Businesses have all these options - including limiting the end-users in a number of different ways - because in a business, the network is there to serve the business. But in an ISP, the network is there to serve the subscribers by providing a common-carrier communications service.

As such, the subscribers of an ISP can and should determine what traffic should be on the network, when, where, and how much. Any methods to alter, curb, slow, or block traffic from the network should be disclosed to the end-user at the very least and should be avoided unless there are no other alternatives - to do otherwise is to create a value judgment on certain types of traffic and to endorse certain types of speech over others.

(Perhaps I'm wrong on this, but…) To my knowledge, no company uses a method similar to "pay-as-you-go" to curb recreational traffic on their networks. They may limit speeds to certain applications, they may block sites, but I don't believe that any company institutes a bandwidth cap on its own employees.

That to me suggests that this plan doesn't have much merit as a solution to ISP oversubscription.

What do you think about Time Warner's plan? Disagree with the author? Feel free to make your opinions heard in our comments section.

By Brian Boyko
Editor, Network Performance Daily

2008. Leap year. Election year. Government deadline for IPv6.

With the exception of the military, federal government agency CIOs are doing the bare minimum required by law to meet the mandate to move to the IPv6 network protocol by June, 2008. That bare minimum, according to this Network World story, is for all the hardware to be IPv6 capable - but does not actually require any IPv6 traffic to go across the network.

Whether or not this delay is a pragmatic consideration or the path of least resistance, most of you are probably having the same reaction regardless of your ideological bent. Liberals can call it typical of the current administration; conservatives can call it typical of government in general. Either way, the reaction that is probably shared by most of us consists of rolled eyes, a resigned sigh, and the word "typical" muttered slightly louder than a whisper under our breath.

For a contemporary example, the HDTV changeover, for example, has been looming "on the horizon" for decades now. At least one person I've talked to in the company has bought what they thought would be the "last SDTV they ever bought" four times since then. I'm still using an NTSC, instead of ATSC (high-def), tuner in my media PC because I don't believe that NTSC broadcasts will cease anytime soon, despite the February 2009 hard shut-off date.

Let's face it. It's hard to get the government to move on something until they have no other choice. This differs from the corporate world in so far as it's impossible to get a company to move on something until you can prove that they have no other choice. Which is one of the reasons government adoption of IPv6 is such an important issue.

Companies are not going to move to IPv6 unless it can be proven that the multiple and numerous drawbacks - reconfiguring an entire network, making sure existing applications (including network management software) are compatible, reconfiguring security, and, oh yeah, that looming $200B infrastructure cost - outweigh the benefits. And of course, backwards compatibility with IPv4 must be maintained until almost everyone is on IPv6.

Additionally, because of NAT and similar technologies (which have some beneficial side effects), the problem can often seem like it can be perpetually postponed. NAT solutions, of course, break P2P apps, impact network robustness by having an additional potential point of failure, and add complexity to the design and deployment of networks. Trying to solve IPv4 address exhaustion with more NAT is like trying to solve global warming with more air conditioning.

And the benefit is that you'll be able to add new devices to the network, and that configuration will be more in-line with the "end-to-end principle." There are some advantages, such as auto-configuration and mobility, some built-in QoS configuration, some new ways to deal with end-user computer security and better routing scalability, but many of these problems have existing solutions in IPv4. Those solutions may be more complex, harder to maintain, and may be less optimal for your network performance, but they exist. So, in short, IPv6's main selling point is that you'll be able to do the same things as you currently do on your IPv4 network.

If that's the carrot, what's the stick? Without it, you'll be less able to communicate with all the other networks that exclusively use IPv6. This does include China, which has already made the switchover, but does not, as stated earlier, include the U.S. government.

You can see why this can be a tough sell. Tons of work for IT, at a time when everyone's got some major project like a VoIP rollout whose benefits are a bit less ephemeral and a bit more quantifiable - all because we're running out of IP addresses.

We've faced problems like this before. But the prospect of running out of IP addresses isn't as sexy or scary as some of the nightmare scenarios that were associated with the Y2K problem. People were stockpiling cans of beans in basements waiting for the Russian nukes to fly and robots to revolt and for anything more sophisticated than the steam-powered abacus to stop working or something like that.

In response to the unadulterated panic associated with Y2K, the U.S. government passed the "Year 2000 Information and Readiness Disclosure Act," which worked with private companies to solve the problem. So what will it take to get governments and corporations to move in a timely manner? Apparently, threat of nuclear Armageddon and a ticking digital clock.

So, until we convince the writers of "24" that Jack Bauer's next adventure should deal with terrorists threatening to blow up unallocated IP addresses, the best plan to move to IPv6 is to get the government to move to IPv6, which will get the government contractors to move to IPv6, which will get everyone else to move to IPv6.

Without IPv6, there is a theory that an impending IPv4 address exhaustion will result in a speculative market on IPv4 addresses. That may very well occur, but such a market would only postpone absolute exhaustion of IPv4, trading of addresses would result in fragmented allocation patterns that would fragment and expand routing tables - older or low-powered routers may not be able to handle the increased load, and, since each change in an IP number requires massive changes to network configurations, there's little market liquidity in it. In short, the development of an IPv4 market might be so disruptive to the operations of the network that IPv6 might be less disruptive.

So, the fact that the government isn't actually moving to IPv6 despite the implied promise that it would, is, therefore, a problem.

Take away from this a simple lesson: sometimes it takes a few bold actors to move forward with broad change even if it seems early to do so. Without those bold actors, the inevitable change may take much longer to reach the tipping point - causing pain and strain for everyone.

What motivates you to changeover to IPv6, or what motivations would you need to change to IPv6? Feel free to leave a comment in our comments section.