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.

By Nathan Bragaw
Business Development Manager, NetQoS

NetQoS European Tech Rep. Peter Frame and I made a trip to Moscow last month to attend a network management event hosted by our new Russian partner, UNICORNS. I thought I'd share a few observations from that trip.

First, the obvious: Russia is cold. I was born in Maine and been in Minnesota in Winter, but Russia, complete with snowfall and brisk wind qualifies as the coldest place I've ever been, and that includes Minnesota in Winter. On the plus side, the food is fantastic - I didn't realize I liked borscht until I ate at Taras Bulba on Petrovka Street - wonderful Ukranian and Georgian food.

It was clear from the wonderful work our local partner, Boris Goldshteyn, did with getting some of the biggest companies in Russia to attend our first network management event in the country that the Russian economy is in full throttle.

I am always fascinated by how different cultures and environments change the needs of our customers. In Russia, it's not that their network performance problems are any different. Instead, they are facing the same problems, like VoIP performance and WAN Optimization difficulties, but they are moving at a faster rate. This is largely because they are not confined by the fiscal restraints that companies in the U.S. face due to the fallout of the dot-bomb era. Companies in Russia want to invest in technology but are challenged to ensure that the technology they seek will meet the needs of their business. The network engineers we talked to there are looking at massive growth, the push for more current technology, and demands for understanding application performance over their networks.

What differences in culture and environments have you found when working on multinational IT projects? Feel free to tell us about them in the comments section of this post.

By Brian Boyko
Editor, Network Performance Daily

I'm sure most of our readers can sympathize with the protagonist in this Daily WTF story, "Illicit Process Improvement." (Indeed, it reminded me of quite a few scenarios from my mandatory high school "computer studies" courses.) Most people who have worked in the bowels of corporate IT departments can sympathize with the situation: Lowly but technically savvy person discouraged from making minor improvements because of a major change, which is perpetually "on the way."

And it does seem that the big project is almost always either perpetually "on the way," until it's forgotten or the project's sponsors have to admit defeat, doesn't it? Indeed, Infoworld has written "On average, about 70 percent of all IT-related projects fail to meet their objectives." That's a staggeringly high number.

Certainly, IT failure rates are one of the reasons it can be so hard to explain how to get business decision makers to invest in IT. I mean, think about it. Would you invest in a business where 70% of the products failed?

This is one of the reasons that IT departments need to quantify the business gains from successful IT initiatives, in order to justify the investment the business makes in IT. And we've talked about that before, especially as it relates to quantifying the value of network performance improvements. But if it's good to quantify your successes, wouldn't it be even better to have more successes overall?

You could argue that IT is just too complicated; that there are too many pressures and personalities in the IT room, and that technology upgrades are just complex and prone to failure. I doubt it though. Sure, WAN Optimization and VoIP implementations are difficult and technical. But commercial satellite launches are technologically complex, and I'll bet you failure rate is less than 70%. Indeed, the Indian Space Research Organization is talking about a 5% launch failure rate in 10 years.

Okay, so it's a false comparison. But if the IT guys are bright people - why does everything seem to fall apart?

I think that it's because of three things.

First: Often, projects are started without a clear understanding of the company's needs, and without a clear sense of the greater goals of the project.

I don't want to get started in on a recursive loop of existential navel gazing; lord knows I've done that too many times in my lifetime. But I think that many projects are started without a clear answer to the question: "Why?" When the project is successfully completed, what will it have accomplished? Is that goal one which will ultimately benefit the business in some capacity, by reducing cost or increasing revenue? Often times, we find ourselves taking on projects without having the purpose in mind - the project itself becomes its own purpose.

Now, this instinct often serves technical people well - we approach technology as an art form, with no particular purpose needed. This is why we were putting together Linux boxes out of old computers in our freshman years of college (or high school) and learning all we could - even though it might have been more productive to stick with our PCs at that time. Technology for technology's sake.
So as we get bogged down in the technicality of things, we ignore the broader questions of why.

And while it probably means more of the dreaded "meetings" which keep us away from our servers, databases, and wires and force us to spend time in boring, dull human contact before any project begins, it's probably a good idea to establish what the ultimate purpose of the project is. If the project can no longer meet those goals, if the project is not the best way of meeting those goals, if the goals become irrelevant - then it's time to change the project to meet the new goals, not the new goals to meet the project.

Second, when the project is underway and a deadline passes, the deadline is often pushed back with no ill consequences.

Projects often limp on for years that way. Furthermore, if you know that a deadline is going to be extended, you're more likely to put those projects on the back-burner, instead of giving them more direct attention. Okay, sometimes the task is harder than anticipated, or more problems creep up than are expected - these things happen. But if you can't meet an incremental deadline for a phase of the project, then you have to ask whether you'll be able to meet the final deadline; and if not, how that impacts the key goals - will the project even meet those goals now?

In short, a missed deadline is a reason to re-evaluate the project - not a reason to re-evaluate the deadline.

Third, there's a tendency for IT planning to develop overarching, long, huge, revolutionary solutions when small fixes are the most efficient solution.

Just speaking from personal experiences, I could have just bought a TiVo instead of going through the steps required to build my own MythTV box.
In the story mentioned at the top of this article, there was a solution that marginally improved the process that was discarded, because of fear that it would interfere with a larger project that never quite materialized. The larger the project, the greater the number of things that can go wrong; and thus, incremental steps of organic improvements are often the best - if not the most sexy - of solutions.

The other extreme, of course, is to keep patching a legacy system far past its workable prime. (A good rule of thumb for when to do the whole thing over again is when you find you can't fix one thing without breaking one other.) But by and large, people often overlook simpler solutions in the pursuit of their own grand plans.

Ultimately, reducing the failure rate in IT projects comes down to the paradoxes of being able to meticulously plan a clear path and being able to recognize opportunities and improvise when they arise.

Of course, these are just my opinions, and I could be wrong. Let us know what your theories on the high failure rate of IT projects are in our comments section below. Of course, we are particularly interested in those that pertain to networking and performance management.

Also, just a quick reminder, our New Years Resolution contest ends tomorrow, January 3rd, 2008, which is your last chance to submit your Network Performance Management Resolutions for 2008 for the chance to win a Nintendo Wii, TomTom GPS system, iPod Shuffle or iPod Nano.

The bloggers at Network Performance Daily and the team at NetQoS would like to wish you and your family a Happy Holiday.

Win a Wii - Enter Now!

May you have a joyous and safe holiday,
May you get everything on your wish list (including the Wii),
May you keep the spirit of the holiday in you all year round,
And most importantly, may this be the one vacation this year
where you don’t get paged in the middle of the night to fix something.

For those of you who read the blog from Austin, enjoy this handy Google Mashup Map of Austin Holiday lights. For the rest of you: Don’t forget to enter our Get Your Network in Shape for 2008 resolutions contest for a chance to win a Wii, a Tom Tom navigation system or an iPod Nano 8GB.

Continue reading "Happy Holidays" »

You can’t measure the quality of a VoIP call without having a set of metrics. While traditional TCP application performance metrics – like transaction time and throughput – are important, they may be difficult to relate to the user experience with the VoIP phone system. There are some user experience metrics that relate directly with call setup performance, however.

First, there’s the delay to the dial tone. In a VoIP system, the phone has to send a message to the call server letting the server know that the phone is off the hook. The call server then sends a message back to the phone telling it to play the dial tone. The time it takes for the message to be sent and the response received is the delay to dial tone.

Continue reading "VoIP Management Series: Key VoIP Call Setup Metrics" »

It’s important to understand each call setup protocol in a VoIP system, because each different call type can involve different components and different protocols.

First, there is On-Net calling, which takes place between two IP phones on the same logical network. In this scenario, the phones use setup protocols like SIP or SCCP to interact with a call server to set-up and take down each phone call. These types of calls are entirely IP based – they’re carried on the network and do not have to go out to the PTSN.

The simplest On-Net scenario, Intracluster Calling, means that both phones are on the same call server or cluster of call servers.

Continue reading "VoIP Management Series: VoIP Call Setup Protocols" »

Often when looking at VoIP quality, people focus on what happens after your call goes through – crackles, drop-outs, and delay aren’t fun, but they’re only half of what you need to worry about with VoIP rollouts.

The VoIP experience begins not with “Hello” but with “eeeeeeeeeeeee.” It begins when you pick up the handset and get a dial tone. The quality of experience of the overall phone systems is shaped not only by the quality of the voice on the other end, but also the availability that the system provides.

Continue reading "VoIP Management Series: VoIP Call Setup Performance" »

The underlying network metrics that affect VoIP call quality are packet loss, jitter, and latency, and if you have good network performance for traditional networked applications, it is not a guarantee that performance will be good for VoIP applications. The real-time characteristics of voice create very strict requirements for network performance.

For example, an inappropriately configured network could have calls that are delayed, dropped, or just plain sound bad. These call quality issues would quickly affect the end-user experience because telephone usage is very user-intensive.

Continue reading "VoIP Management Series: VoIP Management and Network Performance – Part 2" »

Anytime you add a new application to the network, unexpected results (if not outright chaos on the order of the fall of the tower of Babel) often ensue. VoIP is no different and can affect network performance particularly. This is why efficient VoIP management is so important.

Most traditional networked application performance – email, ERP, Web, and database applications, have a few key assumptions. They usually use the TCP protocol, which is reliable and sacrifices time for accuracy, changing for new network conditions. They can usually tolerate packet loss (because of the TCP protocol’s ability to recover) and delay (because there’s no need for real-time throughput.) Applications slow down, but are still usable.

Continue reading "VoIP Management Series: VoIP Management and Network Performance – Part 1" »

Between dial tone, number lookup, ringing, and busy signals, there’s quite a lot that has to happen before you even start speaking and what most people think of as a “phone call” even occurs. Call setup protocols not only do these things, but also perform after-call resource cleanup and statistical reporting.

Each protocol uses TCP or UDP, and a well-known port or ports for communication. Some call setup protocols are used primarily for communication between endpoints (IP phones) and call servers, while others allow for communication between call servers and voice gateways handling calls to and from the PSTN.

These messages, which vary in size and number, handle functions like the mapping of phone numbers to IP addresses, generating dial tones and busy signals, ringing the called party, and hanging up.

Continue reading "VoIP eBook Excerpts: Critical Elements of Your VoIP Infrastructure - Part 2" »