By Brian Boyko, Editor, Network Performance Daily.

Perhaps more than anyone else, Vint Cerf is the creator of the Internet. He co-designed the TCP/IP protocol when he was working at DARPA, and currently serves as the chairman of ICANN. Of E-Week's Top 100 Most Influential People in IT, he ranks at #20. Among the geek set, he is the stuff of legend.

So I was honored to find out that he posted a reply to one of Network Performance Daily's Tuesday links, where I made fun of the idea of an Interplanetary Internet [additional info at Wikipedia] - an idea that Mr. Cerf has been working on with NASA's Jet Propulsion Laboratory.

I was also humbled because that reply was:

Re: Space Internet - You have completely misunderstood the design. We DON'T use TCP or even IP for the long haul. We use DTN - see RFC 4838 and also www.dtnrg.org for details. We use the TCP/IP protocols for onboard spacecraft and also in low delay environments on the surface of planets but DTN for the interplanetary components.

So, on one hand, Vint Cerf read what I wrote. On the other hand, he pointed out - correctly - that I dismissed the idea of Interplanetary Internet far too quickly.

Furthermore, one of the things that I wrote in that article was that it would take about a month and a half for a triple-handshake connection between Earth and Mars. This was, quite frankly, due to a dumb math error on my part. The actual time it takes, based on an Earth to Mars distance of 400 million km, and a speed of light of roughly 300,000 km/s, is roughly 1,333,333 milliseconds - or 22 minutes - 66 minutes for a triple handshake. High latency indeed, but not the two weeks per pass I had originally thought. (Never again will I make fun of the probe that crashed into Mars because of problems converting imperial measurements to metric.) The post has since been strike-through corrected.

I can only say that "a little knowledge is dangerous" and led me to make poor news judgment.

So I offer a personal apology, to Dr. Cerf, to the people at the NASA Jet Propulsion Laboratory, and most importantly, to the readers. Following Dr. Cerf's links has led me to some information that I now find both very interesting and very relevant to people following networking and network performance.

RFC 4838 for Delay-Tolerant Networking Architecture and www.dtnrg.org are indeed very good sources of information about this protocol.

There are many benefits of adding interconnected networks to space technology. According to this Cisco press release, those benefits include improvements in interoperation and security with ground components, as well as additional flexibility in space design.

But the practical applications of the DTN protocol go far beyond space applications as the system is designed to be used among performance-challenged environments. Performance challenged environments include disaster recovery scenarios, the developing world, and various military applications.

The DTN protocol is designed to work with very large delays, including natural propagation delay, such as, for example, the delay between Earth and Mars. DTN is designed to work where standard Internet fails, by using variable-length messages instead of limited-sized packets, by using storage within the network to support store-and-forward operation over multiple paths and long timescales that do not require end-to-end reliability. This requires that space routers have the ability to retain data over a much longer period of time than a standard router, and to be able to retain that data even after a reboot. The DTN protocol also has added security (the last thing you want is Ernst Stavro Blofeld hacking into your spaceship-to-shore communications) and built in classes of service.

Applications that use DTN will also be designed to minimize the number of round-trip exchanges (and hopefully some of those development techniques will make their way into WAN environments.)
So the high-latency, low-reliability environment of outer space requires new protocols and new ways of thinking. And I can't think of anyone else more qualified to develop that protocol than Vint Cerf. After all, he's already got experience in the protocol development area.

Mr. Cerf also directed me to Adrian Hooke at NASA. I plan to ask him some questions about the technology later this week, and look forward to sharing that information with you in a future post.

For those of you who missed our NetQoS Symposium, we were able to get film of NetQoS CEO Joel Trammell’s keynote presentation on how to approach IT executives with network performance concerns. Below is the embedded video.

Richi Jennings: Thoughts on Network Neutrality & The Monash Report: The Two Internets

There's an interesting look at network neutrality and network performance. The Monash Report proposes the idea of two separate Internets - one "Jeffersonian," dumb and neutral, designed to provide the same level of service to all publishers and companies big and small, with legislation to protect it, and the other, "Edisonian," tiered and optimized for high-bandwidth, low-latency apps such as streaming media and VoIP. Curt Monash seems to prefer a system called Tarriff Rebate Passthrough to solve the Network Neutrality problem - which is worth a look, though I'm not sure if it's practical or desirable to "meter" services.

This introductory article, however, is a good rundown of the issues involved in the Net Neutrality debate.

Net neutrality is both necessary and workable for what I call Jeffersonet, which comprises the "classical", bandwidth-light parts of the Internet. Thus, it includes e-mail, instant messaging, much e-commerce, and just about every website created in the first 13 or so years of the Web. Jeffersonet is the greatest tool in human history to communicate research, teaching, news, and political ideas, or to let tiny businesses compete worldwide. Any censorship of Jeffersonet - even if just of the self-interested large-enterprise commercial kind - would be a terrible loss. Net neutrality is workable for Jeffersonet because - well, because it's already working just fine. Jeffersonet doesn't need anything beyond current levels of bandwidth and reliability. So there's no reason to mess with what's working, other than simple profit-hungry greed.

Network neutrality opponents, however, point to evolving and future technologies, technically more demanding than what the current Internet can well support. Their uses are centered on what I call Edisonet - communication-rich applications such as entertainment, gaming, telephony, telemedicine, teleteaching, or telemeetings of all kinds. Reliable, tiered service is needed for these applications, and somebody has to pay for it.

I found that article through Richi Jennings, who takes issue with this summary, however, and brings up an important point: Network services may be better served by locality rather than QoS policy.

I'm not 100% in either camp, but my gut tells me that today's IP routing technology is holding up well. It's the lack of investment in sufficient peering bandwidth and router horsepower that's letting the side down.… Here's the thing... Those of us that live the other side of the Atlantic live with 250ms latency every day, when we connect to services hosted in North America. I dare say the same is true for those on the other side of the Pacific. There's not much getting around the speed of light.

At least, not yet.

NewScientist.com: Take a leap into hyperspace

If the experiment gets the go-ahead and works, it could reveal new interactions between the fundamental forces of nature that would change the future of space travel. Forget spending six months or more holed up in a rocket on the way to Mars, a round trip on the hyperdrive could take as little as 5 hours. All our worries about astronauts' muscles wasting away or their DNA being irreparably damaged by cosmic radiation would disappear overnight. What's more the device would put travel to the stars within reach for the first time. But can the hyperdrive really get off the ground?

Dröscher is hazy about the details, but he suggests that a spacecraft fitted with a coil and ring could be propelled into a multidimensional hyperspace. Here the constants of nature could be different, and even the speed of light could be several times faster than we experience. If this happens, it would be possible to reach Mars in less than 3 hours and a star 11 light years away in only 80 days, Dröscher and Häuser say.

So maybe I was a bit hasty to suggest last Tuesday that Vint Cerf's Space Internet wasn't necessary.

Besides the inherent coolness of the prospect of "hyperdrive in our lifetime," this may indeed be the holy grail to finally reduce the irreducible propagation delay.

But right now, 299,792,458 m/s isn't just a good idea, it's the law. That said, it's amazing what we can do within the law.

San Francisco Chronicle: Researchers break Internet Speed Records

A group of researchers led by the University of Tokyo has broken Internet speed records - twice in two days. Operators of the high-speed Internet2 network announced Tuesday that the researchers on Dec. 30 sent data at 7.67 gigabits per second, using standard communications protocols.

The next day, using modified protocols, the team broke the record again by sending data over the same 20,000-mile path at 9.08 Gbps.

That likely represents the current network's final record because rules require a 10 percent improvement for recognition, a percentage that would bring the next record right at the Internet2's current theoretical limit of 10 Gbps.

Want to hook up your Quake server to that? Not so fast - remember, bandwidth and latency are two different things. You could send data at 10Gbps but have poor latency because each bit takes a long time to travel down the wire. This is one of the reasons that throwing bandwidth at a latency problem doesn't always work.

Norwich Bulletin: Amero case gets longer look.

An update on the Julie Amero case. The sentencing has been postponed a third time to May 18, this time at the request of the prosecution.

Defense attorney John Cocheo had already promised an appeal. With sentencing originally scheduled to take place March 2, Cocheo requested the first postponement due to addition of several attorneys to the case. New Haven attorney William Dow and sentencing consultant Clinton Roberts are involved.

Others see the state's move as a step toward exoneration.

"By taking this action, the Connecticut Division of Criminal Justice has indicated it clearly understands that its mission is 'justice' and not simply to achieve convictions," said Nancy Willard, with the Center for Safe and Responsible Use of the Internet.

Willard penned "The Julie Amero Tragedy," an evaluation and commentary on the Amero case.

By John Mao

We recently released NetQoS ReporterAnalyzer 7.4. This new version was originally conceived as a maintenance release but after talking with customers, we thought it was a good idea to update some QoS policy-related features.

Part of the overall value proposition for ReporterAnalyzer is the ability to validate QoS implementation. Many companies want to monitor what applications, hosts, and conversations are within a particular class of service.

When you start to implement QoS policies, one of the problems you will face is that you may not know if there are any misconfigurations in the network. That could mean that mission-critical applications might be competing with non-critical traffic because it was placed in the wrong service level, or VoIP might not get the low latency and high reliability of the higher service levels.

In previous versions of ReporterAnalyzer, we didn't have the ability to look at unmarked or "default" best effort levels of service for traffic - a service value called "TOS 0." A main goal of this release was to deliver that functionality.

With the new release of ReporterAnalyzer 7.4, you now have the ability to quickly look at your top five classes of services, and if you don't see a particular application, you can drill in to TOS 0 to see if that application shows up in the default traffic where it's unmarked. If you do see it there, there's a very good chance there's a misconfiguration on that particular router for that interface where that application is not being flagged or marked appropriately.

Beyond that, we added the ability to support sFlow, a technology very similar to Cisco IOS® NetFlow, Cisco's flow statistic reporting mechanism. We included the ability to do this on HP devices, initially. Our goal is to expand ReporterAnalyzer to accept and receive all sorts of flow data from other vendors, and we're working on getting certified for IPFix. These are small steps we're taking to get to that grander vision of moving beyond being the standard for NetFlow reporting to becoming the standard in traffic analysis reporting.

ReporterAnalyzer 7.4 should become generally available in the next few weeks after we get some support feedback from early adopters.

John Mao is Product Manager at NetQoS

--------------
More information:

On NetFlow Monitoring

Ted Romer: Should Have Gone With Cisco.com

NetQoS's own Ted Romer has started up a new blog about networking with Cisco products. Entitled "Should Have Gone With Cisco," the current offerings include his worklog of his MPLS test.

First take a look at the BGP vrf configuration for CUSTOMER_A. We are redistributing EIGRP and any connected routes (local interfaces configured with CUSTOMER_A vrf). By bringing the EIGRP routes into this BGP vrf, it allows the EIGRP routes to be exchanged via MP-BGP to the other PE routers. If you don't do this, you won't see any of the networks learned via EIGRP show up under the "show ip bgp vpnv4 vrf CUSTOMER_A" command. Remember, our EIGRP networks get exchanged via MP-BGP in the form of VPNv4 routes.

Okay, so it's not exactly easy reading for the layman. Still, we wish Ted the best of luck with the blog and will probably link back there more often.

Network World: Weaving a Better Web

From the "We're having trouble with latency on our Sao Paulo to Sea Of Tranquility link" department:

"By the end of this decade, we'll have a two-planet Internet in place. We'll have software on orbiters that allow new protocols to make the Internet work across the solar system.

"This is a very exciting prospect," [Vint] Cerf says.

While the Internet can very well extend from the Earth to extraterrestrial bodies, I'm not sure that an interplanetary 'net will be of any more use than the current system of radio transmission. After all, TCP's triple handshake combined with the natural latency of the speed of light does not make for a "zippy" network connection. It takes over 1,200 milliseconds for light to travel from the surface of the moon to the Earth - so whatever other troubles you may have with the network, you're working from at least that much latency to start with.

Earth to Mars? At maximum distances, that's a propagation delay of 1,330,920 ms. A triple handshake alone would take a month and a half to complete, [Ed. Note: Math error] an hour to complete, and that's before sending data. Talk about high latency!

Certainly, in the far off future, when we all have rocket cars and robotic servants handing us margaritas in our fur-lined zero-G chambers, you could set up a batch transmission from one planet's network to the next. But right now we're sending individual probes. I fail to see how an interplanetary Internet would be an improvement over whatever analog radio based technology we've been using in space so far.

SmallNetBuilder: HowTo: Wake on LAN/WAN

Ever need to reboot a computer to solve a problem? Have you ever had to travel out to the site - or walk someone through it - in order to do that simple reboot? This guide might come in handy for you.

In order to take advantage of Wake On LAN/WAN technology, there are multiple steps to perform. This guide lists those steps, covering BIOS configurations, software, testing, routing, and security. The goal here isn't to cover every aspect of Wake On LAN/WAN technology, but to provide understanding and tools to make it work on your network.

RFC 2795

Many people believe that if you got an infinite number of monkeys together on an infinite number of typewriters, they would be able to reproduce all of Shakespeare's works. But what happens next? What is the protocol for "monkeyclusters" and how can one easily sort through the data to find out when Shakespeare's plays had been reproduced? To answer this question: The Infinite Monkey Protocol Suite.

In addition, it would be a waste of resources if such a sizable effort only focused on Shakespeare. With an infinite number of monkeys at work, it is also equally likely that a monkey could produce a document that describes how to end world poverty, cure disease, or most importantly, write a good situation comedy for television [4]. Such an environment would be ripe for innovation and, with the proper technical design, could be effectively utilized to "make the world a whole lot brighter" [5].

The Infinite Monkey Protocol Suite (IMPS) is an experimental set of protocols that specifies how monkey transcripts may be collected, transferred, and reviewed for either historical accuracy (in the case of Shakespearean works) or innovation (in the case of new works). It also provides a basic communications framework for performing normal monkey maintenance.

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.

What is going on? It seems everyone is having trouble with their networks - or at least the part of the network that faces the Internet. Feel free to chime in below - we want to hear your theories on this. Even humor/news Web site Fark.com was down for quite a while.

CNNMoney: Late filers swamp TurboTax

People often assume that because I'm a "21st Century Digital Boy" and do everything from pay 99% of my bills online, meet friends online, get my news and entertainment online, and work online, that I'd be the first person to file taxes online.

I work with computers. I know how badly they can screw things up.

And apparently Intuit now knows that too.

NEW YORK (CNNMoney.com) -- A flood of last-minute tax filers swamped Intuit Inc.'s e-filing system early Tuesday, causing long delays for taxpayers trying to check that their electronic returns had been submitted successfully.

Intuit, which makes the popular TurboTax and ProSeries tax software, posted a message on its TurboTax web site Wednesday morning that notified filers that they could not access their returns.

As a result, filers who had waited until Tuesday's deadline to submit their federal and state income tax forms electronically did not know if their returns were processed by the midnight cutoff.

April 15th is the biggest day of the year for makers of tax prep software, and it's surprising that there wasn't enough capacity planning to handle the surge. I'm certain that Intuit prepared for a surge, but I don't know if they prepared for the surge they got. Here's one way to find out the information you need for capacity planning.

Network World: BlackBerry owes this guy a girlfriend

I can think of several bad scenarios due to poor network performance. I think this is one of the worst, however.

Just as the smoke is starting to clear from today's massive BlackBerry blackout, Rafael Paz, a loss control specialist for a car rental agency, writes to tell me that he has been "getting my e-mails about one to four hours late minimum since yesterday." And it hasn't just been loss control that has suffered, he adds: "This issue sucks. I've been getting grief about it from my now ex-girlfriend thanks to this delay. She thought I was ignoring her e-mails when I was receiving them hours late."

Ubuntu.com: Ubuntu Feisty Fawn released.

I wrote a very lengthy review of Ubuntu Edgy Eft, (Ubuntu 6.10) for HardOCP. I downloaded and installed Feisty Fawn yesterday (well, the latest release candidate, which has remained unchanged from the final version). It is as if Canonical read that article and fixed every single one of the problems I mentioned. Everything works, there is no need to go to the command line for anything (so far), and its just an amazing release.

Needless to say, their servers are getting pretty hammered. [ZDNet]

Feisty Fawn held up better than the protagonist in the animation Bambi Meets Godzilla: Canonical put up a bare-bones home page with just a single logo and a list of "mirror" sites from which the software can be downloaded. Still, the site was unavailable for more than half of the day, according to site availability monitoring company Pingdom.

"We have been absolutely swamped with hits to the Web site and the mirrors," Canonical Chief Executive Mark Shuttleworth said in a conference call. "Fortunately there are 160 mirrors out there, all rapidly updating to include Feisty Fawn. We hope the logjam won't last much longer."

Here's the torrent file, if you're interested. I'm seeding from my home computer.

Network World: Users demand better net hardware mgmt.

Hardware vendors have long supplemented their gear with management applications - take CiscoWorks, for example - but industry watchers say the trend is to make gear easier to manage alongside competitive hardware and by third-party software applications such as CA Unicenter, HP OpenView and IBM Tivoli.

This should come as a shock to no one - one of the reasons we made third-party integration a priority in developing NetQoS Performance Center was because IT guys want to be able to go to one tool in order to manage their network, no matter how many companies made the hardware and software on the network. Multiple administration tools lead to stress and headaches. And with enough stress and a bad enough headache, network engineers, ever the clever sort, will find that the one tool they reach for is a hammer…

ZDNet: Cisco invests in networking start-up Avega

Between Xbox360s being used as HDTV media centers, the AppleTV, and the Windows Home Server, home networking seems to be a growth market. This may be one reason why Cisco decided to invest in Avega - to get into that "home networking" space.

Avega, with employees in the United States and Australia, specializes in technology that can wirelessly connect home entertainment gear such as media center PCs, portable media players, cell phones, stereo equipment, networked storage and set-top boxes. The company has also developed technology that controls and manages these devices and the content it wirelessly shuttles through the house.

Cisco is well known as an infrastructure equipment maker. For years, it has supplied large businesses and Internet service providers with the switches and routers that shuttle Internet traffic from one place to another. Cisco now wants a piece of the burgeoning market for home entertainment networking gear.

Personally, I'm not looking forward to explaining home networking to my parents. Try explaining "The network is the computer" to people who thought for quite some time that the monitor is the computer.

Yahoo News: Researchers Explore Scrapping Internet

The same openness that makes the Internet such a valuable communications medium, leveling the playing field between digital distributors also made it a system without safeguards from hackers and spammers. This story from Yahoo details some of the initiatives designed to "replace" the current "dumb network" Internet.

No longer constrained by slow connections and computer processors and high costs for storage, researchers say the time has come to rethink the Internet's underlying architecture, a move that could mean replacing networking equipment and rewriting software on computers to better channel future traffic over the existing pipes.

Even Vinton Cerf, one of the Internet's founding fathers as co-developer of the key communications techniques, said the exercise was "generally healthy" because the current technology "does not satisfy all needs."

One challenge in any reconstruction, though, will be balancing the interests of various constituencies. The first time around, researchers were able to toil away in their labs quietly. Industry is playing a bigger role this time, and law enforcement is bound to make its needs for wiretapping known.

Or keep it very secret until an exposé in Wired Magazine….

Pittsburgh Tribune-Review: Time stands still for Hempfield teen in lockup

A quick summary of this case: Cody Webb, a sophomore at Hempfield Area High School, made a phone call at 3:12 a.m. to his school's automated line. It was March 11, the day that the new Daylight Savings Time took effect.

At 4:17 a.m., a as-yet unidentified caller phoned in a bomb threat to the school on that same phone line.

However, the school failed to update their phone systems to the new Daylight Savings Time and logged the call at 3:17 a.m.

By now you can probably tell this story doesn't have a happy ending. Cody Webb - a student who, according to his mother, didn't have even so much as a detention on his record - spent 12 days in a juvenile detention facility before someone finally did the math.

High school Principal Kathy Charlton confirmed that some of the district's clocks were wrong because of the changeover to daylight-saving time, which was three weeks earlier this year.

"All the time stamps were screwed up. Some did (change over), some didn't," Charlton said. "Everyone's system had to be set manually. There were a lot of clocks involved."

[Cobb family attorney Tim] Andrews said state police and school officials botched the investigation. The school received 35 calls early on the morning of March 11, and few were actively investigated, he said.

"All it would have taken was 10 more minutes to look at the information. Everybody jumped the gun and caused this kid and his family to go through this," Andrews said.

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.