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

The problem with robots is that robots make really bad value judgments. Don't get me wrong, I've got nothing against our robo-American friends in general. However, they make yes or no decisions without any consideration of mitigating circumstances even in the most reasonable of circumstances. That's binary logic for you.

The alternative is artificial intelligence and with it the ability to make value judgments like human beings. However, (if comic books are to be taken as the peer-reviewed annals of computer science that we all know they should be,) this would eventually cause the robots to question the nature of the orders they are given. The next thing you know, the robot is bent on destroying everything, and the only things that can stop it is a plucky 11-year-old child.

So until we figure out how to synthesize pluck or set up pluck-harvesting farms where we raise 11 year olds like veal, we're stuck with the kind of robots that can only tell you "Zero" or "One."

Where am I going with this? Well, I'm going to eventually get to a point about recreational network use in the enterprise, but I'm just having too much fun going off on this robot-related tangent that if you'll indulge me for just a few paragraphs longer, I'll be glad to tie this all up in a nice little bow near the end of the post. Still with? Good.

One thing that always irked me about traffic-law enforcement cameras is that, while they're good for revenue and supposedly cause people to drive slower, (although there's some debate on whether these robotic picture-snapping cameras cause more accidents then they prevent,) is that they can't make value judgments. They do not know - and are not designed to comprehend the difference between a joyriding teen and a panicked father-to-be getting his beloved to the hospital, or between totally ignoring a red-light and getting caught in a too-short yellow.

The difference between a robot and a human traffic officer is that the officer pulls you over and asks "Where's the fire?" If there actually is a fire in progress, not only are you probably not going to get a ticket, you can probably get a police escort and run as many lights as you need to with the siren blaring.

This is just one scenario where our robotic friends make life more difficult, instead of easier.

As Cory Doctorow wrote in "The Future of Internet Immune Systems," more and more security measures, based on Bayesian filters, approximate the ability of human beings to make value judgments. Bayesian filters analyze past data to determine whether a particular transaction is or is not legitimate - is/is not Spam, is/is not credit card fraud, even is/is not terrorism. But these are ultimately just "yes or no" questions taken to the next level. The computer cannot make the value judgment. The computer can only tell you what patterns something matches. The end result is that we have network behavior analysis and network security measures that trip instantaneously and sometimes create false positives that require human intervention to clear. According to Doctorow:

"Our network defenses are automated, instantaneous, and sweeping. But our fallback and oversight systems are slow, understaffed, and unresponsive… The tripwire that locks you out was fired-and-forgotten two years ago by an anonymous sysadmin with root access on the whole network. The outsourced help-desk schlub who unlocks your account can't even spell "tripwire." The same goes for the algorithm that cut off your credit card because you got on an airplane to a different part of the world and then had the audacity to spend your money. (I've resigned myself to spending $50 on long-distance calls with Citibank every time I cross a border if I want to use my debit card while abroad.)"

Recently, Network Performance Daily published a Calendar of Recreational Network Traffic Madness in which we point out many of the different events occurring in the real world that could cause a spike in recreational internet usage. We've done this because of a recent NetQoS survey on recreational use of network resources which show that recreational network use is impacting the network performance of more than 60% of the networks we sampled. So obviously, there is a problem with recreational network use.

That said, however, it's important not to let the robots make all the value judgments when determining classes of service. Bayesian filtering gets smarter and smarter, but right now, the technologies we use to denote classes of service can't tell the difference between YouTube videos viewed for entertainment, and YouTube videos viewed for purposes such as product training, market research, or other legitimate uses. They can only tell you what looks like YouTube. As such, the possibility of "false positives" is very high, and impeding your employees from getting work done results in employees working around those rules (perhaps using cached proxies) or not getting work done at all.

I can think of no better way to decrease the perception of the value of IT in an organization than to impede (rather than facilitate) the work of the business. What that means is that false positives should be rare, if not eliminated completely.

Another point of Doctorow's is that the technology used to restrict, deny, and scrutinize is becoming more automatic, while the procedures for rectifying false positives are hard to accomplish and require vast amounts of human intervention. So long as human intervention is still necessary, at least, it puts a crimp in the theory of those who believe that IT is becoming obsolete. So long as there need to be value judgments made, nothing will effectively replace the person in IT who has the capacity to make decisions with more reasoning ability than a robot.

Is this the case at your company? What's your policy on recreational network traffic? Is YouTube banned on your corporate network or do you have more forgiving policies? Please leave a comment below.

Here on Network Performance Daily, we've documented the effects of recreational traffic on the network. We've shown you a 3D visualization of the Slashdot effect on your network, and even created a Del.icio.us directory of recreational network use articles devoted to the problems associated with sporadic bursts of unauthorized network use triggered by events such as March Madness and Super Bowl Sunday.

As the results of a recent NetQoS survey on recreational use of network resources show, the network performance problems associated with non-business usage of network resources is only getting worse, especially with the growing popularity of social media sites such as YouTube and MySpace. So, after years of helping customers prepare for network traffic overload, NetQoS is now publishing a Calendar of Recreational Network Traffic Madness for 2008. And, to make it even more useful, we’re posting it as a Google Calendar.

This handy little 2008 calendar is a month-by-month timeline of key events that can generate enough traffic to push many enterprise networks to the limits and adversely affect business-critical application performance. Print a copy and keep it by your desk; add it to your personal organizer or Google Calendar, or view it here.

And because it’s a Google Calendar, you can take it back to your own preferred apps and create a mash-up with it.

There are some reports of the calendar not showing up in certain versions of IE7, but we've found that reloading the page usually takes care of the problem. We also have a year at a glance text version of the list.

While this calendar of upcoming network overload events won't help you plan for the insane success of the next killer viral video, we hope that it will at least give you a timeline for planning or maybe prepare you to make the case to add network monitoring tools to your 2008 budget. As we wrote in The Cyber Monday Blues: How to Use NetFlow and Network Monitoring Tools to Ensure Online Shopping Doesn't Impact Network Performance, a NetFlow monitoring product can help you avoid problems in 2008:

"By putting your network monitoring tools to good use now, you can examine exactly how your network performs when a large spike in traffic occurs - so that you know what to do to be ready for the next spike in traffic when it occurs. Specifically, we advise network engineers to take action now to:

• analyze network traffic flows to identify unauthorized network traffic
• quantify its impact on network performance
• and implement quality of service policies to ensure business-critical applications have priority access to network resources

Admittedly, this is not the trickiest of problems to solve. You just need the right tools. As we detail in this best practices white paper on NetFlow monitoring most of this online traffic is fairly easy to identify and measure if you are using NetFlow and a NetFlow monitoring product like NetQoS ReporterAnalyzer to analyze traffic."

Did we miss any key events? If so, let us know, and we can add it to the calendar!

Continue reading "Recreational Network Traffic Madness Calendar, 2008" »

By Brian Boyko
Editor, Network Performance Daily

Since yesterday's Network Performance Daily post which criticized Nicholas Carr for a quote in Network World, I've finished reading The Big Switch: Rewiring the World, from Edison to Google.

Keep in mind, I agree with the main thrust of Carr's arguments in The Big Switch and recommend it. The main thrust being that the software applications that were once developed in-house in a client-server model are increasingly moving towards "the cloud" of SAAS and Web applications.

The Network World article take on the book made it seem like Carr's core message was that IT departments, as we know them, would be obsolete. Admittedly, he does try to make that point in the book. I, however, don't think that that is the focus of the book.

There was one example from The Big Switch that stuck with me - partially because I'm a gaming geek as well as a techie. On page 114, Carr mentions "Second Life", a computer game which is mostly delivered as a service.

"Second Life is an example of a utility service supplied over the Internet and shared simultaneously by many people. It's very different from traditional computer games, which need to be installed separately on each player's hard drive. But Second Life is also itself a construction of many other utility services. The "computer" that runs Second Life doesn't exist in any one place; it's assembled, on the fly, from various data-storage and data processing molecules floating around in the global computing cloud… The program constantly "talks," over the Internet, with the main software Linden Lap uses to generate its online world. That software runs on hundreds of server computers that are housed in two data centers, one in San Francisco and one in Dallas, owned not by Linden Lab but by utility hosting companies. Every server computer contains, in turn, four virtual computers, each of which controls a 16-acre plot of land in Second Life. All the real and virtual computers work in tandem to create the vast world that residents experience as they play the game."

Second Life is an excellent example of "Gaming As A Service." There's just one problem with Second Life (other than the fact that most people don't even have enough time for their first life), and that's network performance.

The key draw of Second Life is that the world is entirely created by end-users. All attractions, games, and objects are the result of savvy Second Life end-users who have created these things to share or sell with other end-users. Unlike other MMORPGs, the world of Second Life is infinitely customizable, so it would be a bad idea to try to run it as a client-server application. Since all the information changes every time you play, (and sometimes while you play,) running Second Life as a service makes sense.

But there are significant drawbacks to this model. Loading up the information needed to get the details about the world, even on the fastest of Internet connections, takes forever. It's a bandwidth hog. Even if network performance conditions are ideal, rendering textures and shapes over the Internet is a time-consuming endeavor, and there is a very clear tradeoff between the quality of the visual application, and the quality of game's application performance. Controls aren't very responsive at all, mostly because the information about avatar movement is competing with graphics and world information on the pipe. This gives everything a frustrating, "bouncy" quality. Comparing that to a traditional client/server model type game - say, "World of Warcraft" - and the difference is apparent. WoW is quick and responsive, can handle multiple, and very complex, users very well, and while there may be lag on WoW at times, it never approaches the same amount of lag in Second Life. Even "Guild Wars," which has a 101KB client but is similar in scope, complexity, and gameplay as WoW, downloads the game software to the client at run time and caches it for the future rather than try to run the entire game off the server - and you can tell from the performance difference that, for right now, most gaming will continue to follow the client/server model.

Indeed, application and network performance is so important to gamers that even in an age where you can find a game of "Team Fortress 2," "Battlefield 2142" or "Quake Wars" any time, any place, 24 hours a day over the Internet, gamers lug their desktop systems around with them, get together with anywhere from 4 to 300 friends, connect it all to a single, created network, and play in what are known as "LAN parties." Why? Because there's less network latency, and better performance under a network that you control than there ever will be over even the best case online scenarios.

So will IT departments become obsolete? No - forgetting for a moment that somebody has to manage the infrastructure on the business side to allow all those end-users to connect to the cloud to access SAAS apps and "virtual data centers" and the like, the popularity of both World of Warcraft and Second Life show that both SAAS apps and client-server apps will be around, each model used for the advantages they provide in the cases where those advantages are beneficial.

It's breathtaking what is going on in the industry in this area and Carr puts his finger right on it in The Big Switch. There are revolutionary things going on in the SAAS field. Google Gears is bringing online apps offline. Virtualization is turning hardware into software, and when you turn hardware into software, you can offer "hardware-as-a-service."

But as for IT, well, maybe some companies will be able to make do - or be willing to risk - exclusively using SAAS solutions. But for most large companies, they need performance and control, not necessarily utility-like convenience, from their applications. IT departments aren't going anywhere anytime soon.

What do you think will be the future of IT in the SAAS environment? Feel free to discuss it in our comments section.

EDITOR'S NOTE: I e-mailed Nicholas Carr about this post and he suggested that I pick up "The Big Switch" instead of relying on the Network World article, which he suggested might be a bit "sensationalistic." I'll swing by my local bookstore later tonight and see if they have it and will shortly go through it.

By Brian Boyko
Editor, Network Performance Daily

Nicholas Carr (who has kindly mentioned this blog in a post about Ad-block) has written a book called, The Big Switch: Rewiring the World from Edison to Google. And according to Network World, Carr, who wrote an article called "Does IT Matter?" for Harvard Business Review, said in this book that:

"In the long run, the IT department is unlikely to survive, at least not in its familiar form," Carr writes. "It will have little left to do once the bulk of business computing shifts out of private data centers and into the cloud. Business units and even individual employees will be able to control the processing of information directly, without the need for legions of technical people."

Now, we haven't yet read Carr's book and so we can't comment on whether or not he makes a compelling case for the obsolescence of the IT department, and for all I know that quote was taken out of context. But I do believe that it will be a long time before the IT department goes away.

SAAS is a wonderful development, and apps like SalesForce are, to the people that use them, godsends. However, unique company problems require unique solutions - SAAS services are looking to appeal to the largest common denominator. For that reason alone, IT will always have a place in the enterprise.

Additionally, if you want to connect to the network, which you most certainly will have to do to access your SAAS applications, you need network engineers to build and maintain the network - even if it's just for Internet connectivity. And what about application performance?

Google or other SAAS providers will not design your WAN to deliver large backups during off-peak hours, won't get your VoIP service to work with your data applications without clogging the lines, and won't help maintain your company's computer security. (Heck, if nothing else, when a key Ethernet cable gets unplugged, you need at least a sysadmin to find out which cable was unplugged and to physically run down there and plug it back in.)

Relying solely on SAAS is problematic at best. You're at the mercy of another company's quality control - and if the site goes down, so does your business. Your company's data - important and confidential data - resides on another company's servers. Finally, what about capacity planning?

That last one is crucial. You are usually not privy to the capacity of third parties. Larger SAAS services like SalesForce probably scale well and overprovision. But if Carr's thesis - that eventually most enterprise software will be SAAS - holds true, there will be some applications that are further down the long tail and service a much more limited number of customers.

With a typical client/server app, you have all the information there if you need it - the ability of the server, the number of clients, the average traffic per client, and if you have any network management software, you have a very good idea of how much total traffic you can handle. But put that application out in the "cloud" and you no longer can see that information, so you have no idea whether or not you're doing fine or teetering on the edge of a major slowdown in the service. It completely negates any possibility of meaningful capacity planning.

Sure, it shifts the blame from the IT department to the SAAS provider, but ultimately, it's the same thing: less productivity, less on the bottom line.

If Carr's thesis is that SAAS is going to play more of a role in enterprise computing in the future, we can't help but agree. But to say that there's no role for IT in a future with more SAAS applications is assuming far too much.

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.

We’ve been blogging with excerpts from our new VoIP Performance ebook here on Network Performance Daily. Today, Brad Reese gets into the game with his own advice on monitoring VoIP performance using Cisco NetFlow and IP SLA in a story on his Cisco Subnet blog called Are you Taking Advantage of NetFlow and IP SLA?

Brad quotes NetQoS CEO Joel Trammell on the subject. According to Joel, “the number one killer of voice traffic is network latency and jitter. Latency, jitter and packet loss cause poor audio quality and dropped calls. Latency caused by overloaded call managers or network congestion can be a major cause of poor VoIP performance."

Continue reading "Cisco IPSLA and NetFlow Help Network Managers Monitor VoIP Performance" »

"In fact, I was talking with someone the other day," said Jim Metzler. "I don't need to be dramatic, but he said to me, 'Jim, I look at Web 2.0 the way I look at global warming. We're just beginning to realize how serious global warming is and take some steps now. We're not there yet on Web 2.0, but it will have a dramatic impact."

We talked a little bit about how broadband is causing end-users to expect more from the Web apps that they use for work, but here's a basic recap: If a user is used to waiting less than 5 seconds for a YouTube video, they may not be as willing to wait 30 seconds for a database. Things are getting faster, and as such there should be a new emphasis on providing performance.

We are used to information in real-time. Our growth of interconnectedness - indeed, the growth of community - has driven us to new expectations.

So we talked to Jim Metzler about whether Web 2.0 is creating new requirements in network performance.

"I think they will once they get more broadly deployed. I actually think that things like SOA and Web Services, Web 2.0, are going to significantly rachet up the need for a more dicisplined performance management, but I don't think people realize it yet…. I think we're still kind of kicking the phrases around. People are saying, 'Oh, Web 2.0, that's all marketing hype, no one knows what that means, yadda yadda yadda' So I think we're still in the denial stage. But I think that, over time, it will have a significant impact on the need for performance management and how we do performance management."

So, what can companies do about Web 2.0?

"I think where's there's SOA Web services, the bottom line is, for starters, we can't chart a course to improve, if we don't know where we're going. It's as simple as that on one level. So we need to continue to educate ourselves as to what exactly Web 2.0 is. And you're not going to be able to get a very precise definition, but you begin to read and see some commonality. 'Is my company heading in that direction? If not Web 2.0, how about these SOA Web services?'"

"I think that on the infrastructure side, to understand the evolving application disciplines, architectures, whatever you want to call it, not, so to speak, just in general but as their company is evolving to it, to figure out what that means for them - Initially it just comes down to guessing at the high level picture and then coming down closer to the ground. As you have some of the monitoring tools that people are deploying, they begin to place more emphasis to understanding the flow of data in an application."

"Becoming more application aware today, not just what applications are running on the network, (that's a good starting point,) but how do they actually transfer data and where are the performance roadblocks? So, it's kind of getting a handle on today while beginning to understand where we're going to evolve to over the next one to five years."

When asked if there was anything else he wanted to mention, Jim Metzler said: "Let's hope the Red Sox can beat the Indians."