By Brian Boyko

Allan Leinwand at GigaOM has written a story entitled "Web 2.0 & Death of the Network Engineer" about meeting with the CTO of an unnamed Web 2.0 company. There, the CTO said: "The Internet is like electricity. We plug into it and all of the things that you mention are already there for us. We don't spend any time at all on network or server infrastructure plans."

Keeping in current Web 2.0 naming convention, I'm guessing the Web 2.0 service will be called "Xcessive Netwerk Retranzmizzns."

Okay, maybe that's a little harsh, but this attitude baffles me. If your business depends on services provided on the Web, you'd better be able to have a network that can handle the amounts of data requests that are coming in. Sure, you could outsource your data center and networking needs to a third-party service provider, but even then you need to keep apprised of what that service provider can handle - not just what they tell you they can handle.

Service providers often have SLA agreements that sound good on paper, but without independent verification, you can end up being misinformed about your network's capabilities.

One major company's service level agreement stated that managed Internet service latency - round trip transit delay - will be no more than 39 milliseconds. That sounds good, but the method they used to calculate that 39 millisecond latency was, to put it mildly, flawed. They measured the latency between city cores over the Internet backbones, not factoring in last-mile transmission. Additionally, they measured latency as the monthly average of transmissions of test packets - which for all we know could be small, prioritized across the backbone, or both - across these city core pairs. Because the latency was calculated as an average, and not the maximum, a particular network link could have horrible performance over a long period of time, but still average out to be under the SLA the company promised.

But if you didn't walk through the process of calculating how bad performance could get before those average numbers were bad enough to violate SLA for the C-level executives, then all they're likely to remember is the idea that "Company X has a 39 millisecond SLA." You need to "trust, but verify." And you're not going to be able to do that without planning for what you should have.

To extend the unnamed CIO's Internet-as-utility metaphor further, electricity is not 100% reliable either. Do those companies that require 100% uptime for electricity - hospitals, for example - trust that the third-party electric company can meet their needs? No - they have UPS systems and generators.

(Continued...)

Continue reading "The reports of the death of the network engineer are greatly exaggerated." »

By Dr. Mike Johns, NetQoS Product Research Engineer, Netcosm designer

Netcosm started as a bunch of yellow blocks flying between purple blocks. But even at that early stage, the reaction took me by surprise. People from everywhere in the company stopped by to take a look.

The reaction from the Internet at large has also been astounding – but to me, the creator of the software, that reaction has been a bit baffling. What is it about flaming servers, (aside from sheer novelty) that provokes such a response? I believe it is because Netcosm presents network information in a way the brain actually likes to deal with.

There has been explosive growth in the amount of information available to us, and human comprehension is a bandwidth-limited resource. Network engineers are familiar with the general thinking about solutions to bandwidth-oriented problems: either send less information or find more bandwidth.

The fact is, the amount of information processed by the brain is limited by how much information can be crammed through the senses, and the relevance – or signal-to-noise ratio – of what gets through. Sometimes we’re stuck sifting through a lot of noise for the signal we need, so we look for new ways to present it all that simplify the task.

The idea of opening up bigger pipes into the brain doesn’t make a whole lot of sense on the surface. “Upgrading the hardware” is a process that takes millennia. So what little attention has been paid to addressing the problem of increasing the volume of information that the brain can process at one time has become the art of designing the User Interface.

However, typically, today’s business applications tend not to use as much of our natural equipment as is available. Everything tends to get forced through the channels that process text and images. While these are important methods of delivering information, interpreting graphs is a relatively difficult task for the brain to engage in.

But there is a trick we can use. We can process more information in less time by using the brain’s abilities to filter information when it’s delivered in certain ways – specifically, animation and sound. The human brain is exceptionally good at detecting slight anomalies in movement and sound patterns: it helped us eat when we had to kill our own food.

It can take thousands of graphs to convey all of the information shown in 15 minutes worth of Netcosm animation, and most of those graphs would show nothing noteworthy. Instead of deciding how to tell interesting graphs from those that aren't, however, we can instead present everything and defer to the natural abilities of the user's attention mechanisms. It is easier to hone in on what is most interesting in such an animation than it is to sort through thousands of graphs.

By presenting, for example, metrics related to speed as an actual rate of moment, and metrics related to volume by scaling onscreen elements, we have a representation that greatly simplifies the work needed to identify and interpret the most important parts of the dataset.

Once “something interesting” is noticed, the full detail of the data can then be examined in whatever form the user prefers.

I really wish I could say that I began work on Netcosm with these principles in mind. Instead, it was, in the beginning, just something I enjoyed watching. But only after realizing that I was becoming acutely aware of the performance of our internal network as a result of developing Netcosm did I begin to believe in its value as a serious tool.

I could watch was going on while sitting idly in my chair, even when primarily engaged in something else. And when an atypical event did begin to unfold, it was immediately apparent. Whether I was watching attentively, talking to someone, or alt-tabbed in another application, the visual and auditory cues immediately grabbed my attention and let it go when things went back to normal -- which, as someone researching methods of getting the most important parts of very large datasets examined and understood, was exactly what I hoped would happen.

By Eric Hanson

When I got out of the military in late 2000, I came to Austin to make my riches in the tech world. I got here just in time to see the tech bubble burst.

Fortunately, I was able to sign on with a law firm in one of its remote offices as the network administrator/trainer/helpdesk/whatever they needed done. I thought it would be a nice secure job because, as we all know, everyone needs lawyers.

For the first three years, I got to do some really challenging stuff. The firm converted from Novell to Active Directory, and from GroupWise and WordPerfect to Exchange and Office – and everything was going great. I was learning a ton of new technologies and working a ton of overtime (which equated to tons of money!).

Once we got everything done, though, management started isolating the different offices, and started giving us less and less to do. Our role changed from network administration to helpdesk. There were very few projects handed down so needless to say, I got very bored telling people, “reboot your computer.” Very little came across my desk that I hadn’t seen before, so I began surfing the Internet.

This Internet surfing turned into a job search; eventually, I sent out resumes and went on interviews. I was offered a new job with a new title (and new money) at a new law firm. I gave two weeks’ notice and much to my amazement, my current law firm countered, offering to match the new pay and title with the promise of more assignments. I accepted and everything was great, especially with the large pay raise. But less than a year and two small projects later, I found myself right back where I started… “Hello, help desk?”… “Ok, try rebooting your computer.”

So it was back to the Internet for me. I visited every Web site you could possibly buy from, like Craigslist and Ebay, and read every article on Slashdot. I believe it was when I discovered The Onion that I also discovered “Cats in Sinks.”

I thought, there really wasn’t a Web site that featured nothing but pictures of cats in sinks. I thought, maybe it was code for something else… or a joke. Nope, it was cats in sinks. Nothing but cats in sinks. Nearly 60 clicks later I finally resigned myself to the fact that there was no pot of gold at the end of this rainbow. I realized that I had come to the very end of the Internet superhighway, and there was nowhere else to go.

Frustrated, I talked to my office manager, who pretty much told me there wasn’t much more for me to do there, and that I’d probably be working the help desk for the rest of my time at the law firm.

So I took a big risk, and left a stable career to take a contract job, which meant that if I didn’t work, I didn’t get paid, and I didn’t eat. This move was all about the challenge – I was doing absolutely nothing at the law firm. I loved the new job – I was back to doing real work everyday. I didn’t necessarily like the work, but it kept me busy, and I was learning stuff again – I’d come in at 8:00 AM and before I knew it, it would be time to go home.

Toward the end of the contract, I began looking for a new job and found one at NetQoS where I get to work toward a goal and learn a lot more about networking and performance. That’s one of the big things about my job that gets me in everyday before my boss.

This brings me back to the cat in sinks part of my story. Companies often think they can throw money and benefits at people and they will be happy. However, as I found out, money isn’t always the great motivator or a cure-all.

Companies also tend to take this approach with networks. If there is a problem, buy a new server, a new router, more bandwidth; no matter what the issue is, money should fix it. As with my story, money might help but unless you figure out the root cause of an issue, money is only a temporary fix. Until you fully understand the issue and its cause, no matter how much money you throw at it, you still end up with cats in sinks.

Eric Hanson is a trainer in technical communications at NetQoS and recently taught the NetFlow certification course at the 2007 NetQoS symposium.

Netcosm may look like a video game. But it’s not. It may have explosions and fire, but while it looks like Space Invaders, it isn’t Space Invaders.

Netcosm is an experiment in network data visualization designed to provide a “low cognitive burden” visual metaphor. In other words, it is meant to be as simple to understand as a child’s toy, it is not meant to be a child’s toy.

Still, many people talk about how they’d love to “see the network packets fighting” or would like to see it turned into a game.

I’ll admit that when I first saw Netcosm, it did remind me of the games produced by British game publisher Introversion, which include “Darwinia,” a game about a AI computer simulation, “Defcon,” a global thermonuclear warfare simulator inspired by the 1983 movie “WarGames,” and “Uplink,” about network computer security. All of these games have a “retro” feel to them.

So we’d like to throw this out there: “If you were going to turn Netcosm into a video game, how would you do it?”

DISCLAIMER: This does not mean we’re planning to do such a thing, but it does set the imagination afire. For example, if you could turn network administration into a game you can also turn it into a training simulation. Repeated “playings” of simulated scenarios can help network pros recover faster when the same situations happen in real life. And of course, it would be a hoot if tomorrow’s network administrators and engineers became familiar with the tools of enterprise networking through games played as teens – while people today have to start working for an enterprise before they have any “hands on” experience with enterprise networking.

We’d love to get your thoughts on this.

While we had the chance, we also wanted to thank TechCrunch, Kotaku, and Fark.com for linking to us. The YouTube video has almost 49,000 views, and over 6,000 unique visitors have come to the NetQoS site in the past week.

Our NetQoS Symposium continues into the third day. Here's a rundown of today's events:

First, at 8:00 a.m., there's the registration and breakfast.

Then, at 8:30 a.m. in the Darrell Royal Ballroom, Dr. Cathy Fulton, CTO of NetQoS is going to be presenting our third keynote, entitled "Maintaining Visibility in a World of WAN Optimization."

There is a 15 minute break between all events.

At 9:45 a.m. - 10:45 a.m.:

• "Measuring the Effectiveness of QoS policies" with Shane Bordeau in Darrell Royal A.
• "NetQoS Product Configuration Best Practices" with Stuart Robertson in Darrell Royal B and C.

11:00 a.m. - 12:00 p.m.:

• "Advanced SuperAgent Spanning Best Practices" with Eric Robertson in Darrell Royal A.
• "Maintenance Best Practices" with Stuart Robertson in Darrell Royal B and C.

Those taking the NetFlow Certification Review and Test will need to be in Live Oak from 9:45 a.m. to 12:00 a.m. where Eric Hanson will administer it.

Finally, the Symposium will conclude with lunch at noon in the Hill Country Dining Room.

Netcosm has recieved so much interest and response that people are wondering why we're not offering this as a product or at least offering it as a demo.

The truth is, Netcosm is a cool piece of software developed in our research labs, and we wanted to show people some of the cool technologies we were working on. It was a research product, and we didn't expect the amount of response it got. (Although we admit, we were really, really hoping...)

So if you call up our sales guys and ask for Netcosm, you're going to get the stock response that Netcosm is a research project and is not for sale.

This is for a couple of reasons. While Netcosm is cool, we haven't tested it much in real world situations. Sure, we've got it running on our network but we really aren't prepared to sell a product when we can't guarantee that it will work in our customers networks. It's new code.

Secondly, we may have to recode the thing from the ground-up. Netcosm in its current form is really just a proof-of-concept. However, it requires some hardcore graphics hardware that is more likely to be found in consumer computers. And while the graphics are cool, displaying cubes, spheres, packets, and some simple smoke and fire, should not take nearly as much GPU power as it currently does. we'd like it to take less GPU power. We'll probably We might have to switch out the backend graphic engine - maybe using an early version of DirectX or moving to OpenGL, or maybe even developing our own graphics system in-house.

Because we have so far to go before we can even begin to offer this as a beta version of a product, it would be unfair to customers to promise this to them as a future product.

So, are there any plans to release this as a product? Not at this time - not until we consider it good enough to even consider releasing it as a product.

But don't think the interest has gone unnoticed.

[Editor's note: Corrections made to improve accuracy after receiving clarifications from Dr. Mike Johns.]

Our NetQoS Symposium continues into a second day. Here's a rundown of today's events:

First, at 8:00 a.m., there's the registration and breakfast.

Then, at 8:30 a.m. in the Darrell Royal Ballroom, Issy Ben-Shaul from Cisco is going to be presenting our second keynote, entitled "A Multi-Layered Approach to WAN Optimization and Application Acceleration."

At 9:45, Mike Ellis will present NetQoS Product Vision and Strategy.

We'll resume at 11:00 a.m. and follow this session schedule. There is a 15 minute break between all events, and lunch at noon in the Pavilion outdoors.

11:00 a.m. - 12:00 p.m.:

• "Cisco IP SLA Deep Dive" with Ernie Mikulit from Cisco in Darrell Royal A.
• "Retrospective Network Analysis with GigaStor" with Charles Thompson from Network Instruments in Darrell Royal B and C.
• "NetFlow: Metrics Overview and Traffic Analysis" with Eric Hanson in Live Oak.

1:15 p.m. - 2:15 p.m.:

• "Quantifying Network Performance in an MPLS Environment," with John Mao from Cisco, in Darrell Royal A.
• "Real User Monitoring with Coradiant and NetQoS" with Alistair Croll from Coradiant in Darrell Royal B and C.
• "NetFlow: Security" with Eric Hanson in Live Oak.

2:30 p.m. - 3:30 p.m.:

• "Using SuperAgent to Demystify Application Performance (Part I)," with Tim Smith, in Darrell Royal A.
• "GigaStor Sizing Considerations," with Nathan Bragaw in Darrell Royal B and C.
• "NetFlow Managing Enterprise Applications" with Eric Hanson in Live Oak.

3:45 p.m. - 4:45 p.m.:

• "Using SuperAgent to Demystify Application Performance (Part 2)," with Tim Smith, in Darrell Royal A.
• "Case Study: Deutsche Telekom - Portal Integration of SuperAgent" with Martin Glogowiec from T-Systems in Darrell Royal B and C.
• "NetFlow: User Monitoring" with Eric Hanson in Live Oak.

Finally, at 6:30 p.m, we'll have our Network Social with dinner in the Pavilion with entertainment from the band Reckless Kelly.

What happens when a high profile Web site links to your site?

“Slashdotted.” “The Digg Effect.” Even “Farked.” A product announcement, a cool blog post (on Dungeons and Dragons, perhaps?) and your server gets a sudden spike in traffic.

Ever wonder what that looks like? Sure, you could graph it, but have you ever wondered how it would look like live?

Below, we’ve got a video of the effect (from a simulated “Slashdotting”) and what happens to your network.

Netcosm is a three dimensional video game-like graphical representation of your network and the traffic that traverses it. Initially developed in NetQoS Performance Labs as an experiment in low cognitive burden network monitoring, it allows you to view at a glance the health of the network. Sure, you could get the information from viewing text-based reports and 2D graphs – and this isn’t a replacement for them – but it does allow you to get information about the performance status of your network literally at a glance. Dropped packets are ejected from the stream and detonate in a fiery explosion, servers struggling under load are depicted first as smoking, then as on fire.

Audio cues also determine the health of your network so you don’t even need to be looking at the screen to keep an “eye” on your network – you can “hear” the file crackle and the packets explode, so you can work on other problems while always being aware of the network in the background. Hear the sound of a server crackling or a multitude of explosions?

It’s our way of making hard-to-detect, subtle network performance problems… a bit less subtle, and therefore, easier to detect.

In Netcosm you can move around and zoom in on particular parts of the network or even one server, and you can zoom out to take a look at your entire network. Controls are familiar to anyone who has ever played a three dimensional computer game like Doom, Quake, or World of Warcraft – and that’s not unintentional. The generation coming into the IT rooms today grew up with video games – and will find this tool familiar.

Below is a video of Netcosm in action. Let us know what you think of it in the comments below.

By Brian Boyko

Until recently, I underestimated the value of a good error message.

Recently, I wrote two articles for HardOCP detailing my experiences with Ubuntu Linux and with Windows Vista. Both have flaws and high points, and I'm not going to get into playing the "which OS is better" game.

But there is one area, however, which I do want to compare, because it caused me professional consternation and it is one that is usually overlooked.

Error messages.

(Continued…)

Continue reading "Editorial: The value of a good error message." »