The Ten Other Reasons To Attend NetQoS Symposium 2008.

As you may know, NetQoS's annual Symposium will be held April 20-23, 2008 at the Barton Creek Resort in Austin, Texas. And if you're not familiar with the Symposium, it's three days of presentations, workshops, training, and entertainment.

Combining the best parts of "seminar," "study group," and "shindig," the marketing department has come up with ten reasons to attend the Symposium. You can view these on the Symposium Web Page, but we'll just re-iterate them here.

1. Hone your skills at Network Performance Management Best Practices Workshops.
2. Broaden your horizons and hear about emerging trends in the General Sessions delivered by leading network management experts.
3. Maximize the value of your NetQoS investments through product-focused best practices tutorials.
4. Roll up your sleeves in Hands-on Labs with NetQoS technical experts.
5. Don't just take it from us, benefit from real-world examples, presented by your peers in Customer Case Study sessions.
6. Advance your skills by attending Cisco IOS® NetFlow Boot Camp and network traffic analysis best practices.
7. Enhance your career through expanded technical tracks on:
   • Networking Theory and Best Practices
   • Network and Application Performance Management
   • WAN Optimization
   • Next Generation Network Operations
   • Network Behavior Analysis
   • VoIP Call Quality Monitoring
   • Packet-level Forensics, Capacity Planning, Troubleshooting, and more
8. See the future at NetQoS Product Roadmap Sessions.
9. Flock to Birds of a Feather sessions to share advice and collaborate with your peers on the topics you care about most.
10. Keep Austin weird and experience "Austintatious" nightlife. Enjoy Texas BBQ and Live Music Entertainment provided by Mingo Fishtrap at Stubbs.

However, those aren't the only reasons that you should attend. Goodness gracious no.

Here are the top ten real reasons to attend Symposium 2008.

1. First 100 confirmed attendees automatically become Libertarian Party delegates.
2. Pulse-pounding action as you ride "The Elevator™!"
3. Finally, an excuse for over-40 year olds to come to Austin!
4. Barton Creek Resort's Fazio Foothills golf course is a lovely shade of green in April, is considered the best golf course in Texas, is par 72, 7,125 yards long, and if you hid a body there, no one would ever find it.
5. On Tuesday, April 22, Texas BBQ and Live Music Entertainment will be provided by Mingo Fishtrap at Stubbs. On Wednesday, April 23, Pizza and a Dungeons and Dragons Session will be provided by Brian Boyko at his apartment.
6. Discuss the results of WrestleMania XXIV, and hypothesize about the results of the upcoming Backlash Pay-Per-View event, with your intellectual peers.
7. Feel invigorated by knowing that, due to Texas's liberal "concealed-carry" laws, any of your fellow network engineers could be "packing heat."
8. Every fifth application delivery controller at the symposium is filled with delicious candy!
9. Every day starts with a prayer session, thanking Huitzilopochtli, Left-Handed Humming Bird, for postponing the end of the world. (We will choose an MCSE to sacrifice at noon the previous day.)
10. Slumber Party!

You've probably already seen the video below. 2.6 million people already have.

Obviously, the material covered is amazing and it's an ingenious hack - the fact that the rig consisted of some cheap goggles, LED lights, and a $40 kid's toy hooked up to a PC made it even more impressive.

NetQoS is working on our own user-interface initiatives. Network management software can be hard to grasp - it's a complicated subject - and so the user interface for our products have to be designed with human interaction and ease-of-use in mind. Network engineering is hard, we don't want to make it harder. This is why we've spent a great deal of time working on the interface of NetQoS Performance Center - and we've been pushing the boundaries of network monitoring UI design with our Netcosm project in the NetQoS Performance Labs.

This reminded us that it was probably a good idea to check in with Dr. Jon Schull, a professor at Rochester Institute of Technology who specializes in human-computer interaction and asked him what he thought about the video. Dr. Schull had previously helped NetQoS get the "Netcosm Immersion Experience" up and running at Cisco Networkers in 2007, and we wanted to get his input on this development.

"My main thought was: 'Johnny Lee has done it again,'" said Schull. "If you look at his Web site, you'll see that he's done half a dozen really interesting hacks involving the Wii and another half a dozen involving other things. He's a very interesting and creative guy. This particular one is… is just cool!"

"I don't know how likely it is for us to see this in [gaming] practice, just because I think increasingly the Wii is a social gaming platform, and this is mostly a one-person interface. But, these are the early days and I can see that people are already thinking of ways to have this work for more than one person."

It seemed impressive in an industrial age of multi-person programming teams and high-tech equipment costs, that this was all done with relatively cheap consumer-level equipment.

"There's this other movement that's going on - and this work is exemplary of it," explained Schull. "If you look at Make: Magazine and Instructables and a Web site called 'Hack-a-day' you'll see there's this whole emerging sub-culture of people who are… getting to interesting new results faster by disassembling and reconstructing things from consumer products than by trying to develop these new technologies from scratch."

"I guarantee you there are people who are making those systems right now - they're going to Home Depot, they're getting the goggles, they're getting the Infrared LEDs, and they're having some fun with it. A couple months later, someone's going to sell a kit, and a few months after that, someone will have found a distribution channel for a retail product… That $40 Wii remote contains an accelerometer, a Bluetooth transmitter, an infrared camera - there's an amazing amount of hardware in that $40 item. Eventually someone will put them together in a new device which is optimized for new uses."

Schull pointed out that these new uses are usually found and implemented within months, rather than decades.

"Within weeks, [of the Wii release] you had people figuring out how to hack the Wiimote to use with computers… There are already on the market designed for PCs which are clearly Wii knock-offs. It took less than a year for those commercial products to come out. I think you'll see things like this within six months because Johnny Lee's video has been traveling like crazy. Off the top of my head, it's usable in games, looking at 3D models of architectural sites, 3D models of medical anatomy. There are some major applications - and those latter two could be six-or-seven figure products."

"Another venture of this sort is the whole Multi-touch phenomenon. You've certainly seen the iPhone now, where you can use more than one finger, and you can rotate and drag and move images around by laying hands on them in a way that wasn't possible two years ago. Just two years ago, we saw another set of videos taking the world by storm by a guy named Jeff Han, who demonstrated all the things you could do with multi-touch interfaces. It was approximately a year before it was part of an Apple product."

Schull's work at Rochester University of Technology in Interface design has helped him to design a product like this himself - a large room called the "Collaboratorium" which consists of multiple projectors in a large, enclosed room with a camera that can be controlled remotely. We asked him what was more difficult for innovators - coding the software and hacking the hardware, or just coming up with the vision for new and innovative ways to interact with computers.

"The funny thing is, I think the hardware and software problems are pretty straightforward right now. The social - and market issues are really the tough ones… We haven't seen a room-sized head-tracking stereoscopic multi-touch environment for cheap. Not because you couldn't put one together for cheap, but because it'll be another 6 to 12 months before they get integrated, and then you have to deal with the packaging. No, the real challenge is going to come from defining some come of human interface device standard which will let these things work by themselves or in combination without having to rewrite software for each configuration."

Considering that we at NetQoS have been experimenting with new and interesting user interfaces for network monitoring software, we'll keep an eye - and two infrared light beams - on this technology.

Do you see a use for head-tracking 3D software in your enterprise? Tell us about it by leaving a comment!

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.

It's interesting that we're coming out with an announcement about our support for Cisco Application Control Engine modules and appliances today, considering it's the same day when Juniper announced that it's not going to continue their DX application acceleration offerings. Juniper made the decision, because, according to Network World, "[Juniper] regards it as insufficiently distinguishable from competitors' devices."

Application accelerators and application delivery controllers can indeed be hard to differentiate. As one poster on Fark (and I have no idea how it ended up on Fark) put it, "The load-balancer market is starting to commoditize. This is not unlike the HTTP cache market about ten years back."

We just put out a press release with details about our support for the Cisco ACE application delivery controller. The NetQoS Performance Center and its application response time, network traffic analysis, and device performance modules are available today, integrated with Cisco ACE - a module to Cisco's CAT6500 switch and 7600 series router which provides load balancing and content switching, focusing on acceleration, security, and availability.

And it's particularly important because one of the reasons that this partnership developed was because players in this market, including Cisco, are looking for ways to differentiate their offerings.

One of those ways is being able to quantify the performance gains of the solution - with NetQoS Performance Center integration, network engineers and sysadmins can tell exactly what benefit they got for their investment in the hardware. Being able to justify your budget easily and quickly is a major selling point, and while there hasn't been a lot of focus on using response times to measure the effectiveness of load balancers, it seems a logical next step, considering we've already worked with Cisco before to provide this functionality in Cisco WAAS WAN Optimization devices.

Often, network engineers are forced to rely on CPU utilization, memory utilization, and disk usage as measurement. However, in order to really get an idea of how the application is performing for the end user, network engineers need to baseline and track server response time and application performance. In order to continue to provide good performance for the end-users, it's important to get alerts when deviations from normal performance occur and automatically investigate the source of performance issues. Combining response time metrics, historical SNMP data, and NetFlow traffic analysis is a very powerful combination.

Now, I can't tell you that there aren't perhaps other ways to differentiate your offerings. If I had a solid but unremarkable application-delivery controller and I was trying to compete with the Cisco ACE/NetQoS Performance Center integration, I could probably… paint it pink or something. You know, so that it stands out in the data center, so that people looking around will say: "Hey, what's that pink box?" Would spread word of mouth, maybe.

Or I could give away beer from a microbrewery with every purchase. I know a guy named Orf who has his own brewery. He's a good guy.

Wait! I've got it! every fifth application delivery controller is filled with delicious candy! Mmm, Candy…

What would make you choose one application accelerator over another? Please leave a comment if you'd like to chat about this. Or want candy. Mmm, Candy.

by Brian Boyko
Editor, Network Performance Daily

Anne Bednarz, Network World's associate news editor, is currently compiling a followup to "Five Raves" in which customers talk about their favorite, must-have products. The idea is that the solicitations for suggested topics come not from a company's PR department or from a reviewer but from the IT pros that have to use the products in the field.

To contribute your views, feel free to e-mail Ann Bednarz at her Network World e-mail address, and she'll give you a quick phone call, talking about why you chose the product in particular, why you like it, what business problems it addresses, etc.

Now, you may think that we, a network performance management blog for a network management software company that makes many of these products may be mentioning this because we want you to write in and tell Network World that our products are the best. Unfortunately, it would be unethical to do so.

It is NOT unethical because it would be wrong to ask for such a favor. It is unethical because it has been made clear to me on a recent visit to one company's data center that NetQoS may not, in fact, make the most important IT-related product of all.

This small company, which shall go unnamed here, used to have major network problems - servers failing, corrupted data from hard drives, and occasionally, physically damaged servers. Worse still, these problems seemed to coincide with whenever the boss angrily walked in! And while I'd like to say that their problem was solved by application performance monitoring, NetFlow traffic analysis, or device performance management, they managed to fix the problem with an in-house solution, that I call the "DoorSlinky™."

This device, I believe, will revolutionize IT. It greatly increases the capacity of acceptable force levels used in IT environments on ingress and egress installations. The DoorSlinky™ provides added insurance against data storage failure or network disconnections caused by, but not limited to: blunt force, sudden impact, excessive pressure, rapidly-subjected stress upon the various types of aperture technologies found in IT environments, which is important because as we all know, IT can get very frustrating.

While application performance monitoring and response time measurements can help identify whether your current IT problem is in the application, server, or network, until that is determined, your application team, server team, and network team could fly through IT's doorway in a fit of anger, trying to place the blame on any IT team other than their own. Here, the DoorSlinky™ prevents a bad situation from becoming even worse.

And while VoIP Performance Monitoring can help you ensure VoIP calls go through, until then, people will most likely be communicating by running into each other's offices. Here the DoorSlinky™ also preserves existing physical-layer infrastructure necessary for separation of discrete workspaces.

Finally, while SNMP polling products may help you identify problems with infrastructure availability and resource consumption, no device performance management tool on the market makes the cool "Sproinggggg!" sound of the DoorSlinky™ in use.

For that reason, we undoubtedly endorse the DoorSlinky™ as the IT product of choice for 2008.

Disagree with our selection? We humbly invite you to suggest one of the NetQoS line of network performance management products. 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.

Two major acquisitions in today's news.

First, Sun Microsystems, (not to be confused with the actual Sun, which has a rather lower page rank than Sun Microsystems despite the fact that the nuclear fusion inside its core is the indirect source of all the energy, and thus life, on Earth,) has bought MySQL AB for $1B.

MySQL AB owns the copyrights to most of the code behind the MySQL database. This is interesting because Sun has been doing quite a bit to promote PostgreSQL as an alternative to MySQL recently. (PostgreSQL supposedly scales better than MySQL, and has more features, while MySQL is supposedly more lightweight. Both PostgreSQL and MySQL are open-source solutions, and we interviewed Jason Potanski of the Citizendium project about why Citizendium chose PostgreSQL instead of MySQL.)

But the biggest thing to come out of it might be a simplification of the licensing issues associated with MySQL. The way I understand it, MySQL AB released the code for MySQL under both a proprietary license and the GPL. MySQL AB then claimed that if you wanted to use MySQL as the database for your proprietary application without releasing the source code to it, it was in violation of the GPL and that you should instead buy the proprietary license. Of course, the problem was that MySQL wasn't part of the application itself, it was just the database that the application ran on, and people were just using MySQL's protocols.

Sun has done well with the licensing terms of its many other open source projects (OpenOffice.org, Solaris, Java…) and perhaps they might re-release the MySQL code under terms such as the LGPL (which allows for proprietary applications to dynamically link to LGPL code,) which would end the legal issues.

NetQoS actually uses MySQL in many of our network performance monitoring products, so this is big news for us.

The other big announcement is that Oracle, not to be confused with Gloria Foster, who played The Oracle in the first two Matrix movies, has bought middleware provider BEA, not to be confused with Bea Arthur… this joke has run dry, hasn't it?

Anyway, BEA Systems was bought for $8.5B, in a second round of offers, further consolidating Oracle's middleware offerings. The most interesting commentary seems to be coming from BEA employees who commented on Slashdot's earlier story on the rejection of the $6.7B offer from Oracle.

How do you think these acquisitions will affect enterprise IT? Feel free to leave a comment.

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.

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.