Other than Unix Beards and “funny” T-shirts with hex code on them – which more accurately qualify as fashion disasters – the biggest project disasters in IT, according to today’s top story in Computer World, tend to repeat themselves:

When you look at the reasons for project failure, "it's like a top 10 list that just repeats itself over and over again," says Holland, who is also a senior business architect and consultant with HP Services.

You’ve got your usual run of top-ten disasters in the article, including IBM’s Stretch project (Overpromised and underdelivered), Knight-Ridder’s Viewtron (misread the market), California and Washington States’ DMV overhaul and FoxMeyer’s ERP program, (didn’t make sure the new system worked better than the old one), Apple’s Copland (succumbed to feature-creep), Sainsbury’s warehouse automation (just plain didn’t work), and Canada’s Gun Registration System (cost much more than anticipated due to poor planning), and three U.S. government projects (multiple failures with perhaps more in the future).

But one of the things that I noticed was that it’s relatively rare (not unheard of, but relatively rare) to see networking take a prime role in the huge IT disaster stories that get passed around the campfire during IT tribe meetings. And I think that there are a few reasons why that is – the first is that most of these blunders would fall under the category of “strategic errors” as opposed to “tactical errors.” That is, network problems are usually subtle errors caused by mis-configurations and highly technical mistakes. The networking screw-up can be one of the most subtle, stealthy types, compared to the grandiosity of all-out strategic incompetence.

Or in other words, networking performance problems can cause the best laid plans to often go astray; the worst laid plans need no additional help.

Take, for example, a common error from back when they were first rolling out VoIP deployments – companies would roll out VoIP on the network as if it were just another data application, but then found that their other applications slowed to a crawl or even stopped working.

The problem was that VoIP packets are based on protocols designed to use as much of the pipeline as possible, while most applications are based on the TCP protocol, which is designed to throttle back it’s use of the pipeline if packets don’t go through. So what happened was that the VoIP packets would take more of the pipe, TCP applications would be crowded out and drop packets, which would cause the TCP protocol to throttle back, and the VoIP packets would now see the free space and take up more of the pipe, crowd out TCP packets and TCP would throttle back… creating a vicious cycle.

Was this a problem with strategy? Was it some form of bureaucratic incompetence? No – it’s just that it was a very subtle effect and if you didn’t know enough about the TCP and VoIP protocols (or even if you did, but didn’t put two and two together until it was deployed) you ended up with a problem.

Networking problems may have major effects but they’re rarely caused by major boneheaded screw-ups. I think that’s one of the reasons why the two major areas where IT departments spend a great deal of money – networking and security – is because those two problems are extremely subtle to detect and tricky to solve; security problems by malicious design, networking by nature.

Networking problems are subtle, can strike quickly, can often leave little trace of their presence. They’re the ninjas of IT problems.

Of course, ninjas can be defeated.

EMA analyst Dennis Drogseth had a column in Network World yesterday talking about end-to-end application management. In it, he had this to say:

You might believe, and with some real justification, that the term “end to end” is only used by vendors who custom-fit the definition to the scope of their particular product.

Does “end-to-end” application management, for instance, include the mainframe? You bet it does if you’re a vendor that manages the mainframe environment! Does it include capturing the end user experience at the end station, desktop, or mobile device? Once again, the answer is a definitive “yes” if you’re a vendor that has strong QoE (Quality of Experience) roots. Or how about insights into the code and design of the application itself? If you’re one of the few vendors that does this, you’re proud of it and wouldn’t have it any other way!

And this concerned me because, if you do a google search for: [site:networkperformancedaily.com “end-to-end”], you get 122 results. The phrase, “end-to-end” appears in a little more than 1 in 5 posts we’ve made to this blog.

So, what do we mean by “end-to-end?”  We’re usually using the phrase in connection with network response times and the end-user experience at the end station; NetQoS is a “vendor that has strong QoE roots.”

Now, we do have some insight into the code and design of the application.  But that isn’t the focus of our tools; the focus is to tell you whether the problem is in the network, server, or application, and if it’s in the application, give you a good idea of where to start your investigation.  (For example, an application that is slow due to unnecessary round-trip transactions behaves differently from an application that is slow due to a memory leak on the server where it is being run.) 

Drogseth is right when he says that no one vendor is optimized to do it all.  In the future, there could be, but then you run into the quality vs. quantity problem.  Is it better to do it all adequately or to do a few things extremely well?

EMA defined five major technology spheres, and last June, they polled more than 400 respondents to find out which of them they believed “most critical to end-to-end application management in 2008.”  The answer was “Network Application Management,” focusing on application flows and end-to-end (as we define it) transaction capabilities. 

For more information on this, I recommend you read the original article up at Network World.  Additionally, Drogseth promises to follow-up in his next two columns. 

Get out your valium.

Bloomberg: U.S. Stocks Drop, S&P 500 Sinks Most Since 2001 Terror Attacks

The Dow Jones Industrial Index, simultaneously economic barometer, canary in the coal mine, and metaphor for America’s hopes and dreams, has dropped 500 points in the worst slide since the September 11^th attacks.

Was it the Lehman bankruptcy, (the largest bankruptcy in U.S. history,) that did it? Or the forced sale of Merrill Lynch to Bank of America? Or was it the federal takeover of Fannie Mae and Freddie Mac? Or AIG needing a federal bailout?

No. It was me.

I removed the tag from my mattress that says “Do not remove,” and, well, it was the straw that broke the back of the American economy, apparently. Sorry about that.

More seriously, I’m sure that among those who still held Lehman Brothers stock Tuesday morning, those who managed to sell first ended up (relatively) happier than those who came after them. It just reinforces the idea that in today’s market, you need to take every step to monitor your network and be proactive about problems. (Because when the market is in a panic, you need to be making bad decisions faster and more reliably than anyone else out there.)

PCWorld: HP Announces 24,600 Layoffs in Wake of EDS Acquisition

When it rains, it pours.

Hewlett-Packard will lay off about 24,600 employees over the next three years in an effort to streamline the company following its US$13.9 billion acquisition of Electronic Data Systems last month, the company announced Monday.

The layoffs will be part of a three-year restructuring program, HP said in a statement. The company will lay off about 7.5 percent of its workers during that time, with nearly half of the reductions coming from HP's U.S. workforce, HP said.

Can things get any worse?

Cnet: Forrester slices 2009 IT spending projection

That was supposed to be a rhetorical question!

IT spending is expected to rise 5.4 percent this year, revised from previous Forrester projections of a 2.8 percent increase.

But next year, growth in IT spending is expected to get whacked down to 6.1 percent from previous projections of a 10 percent increase.

Forrester, which revises its annual projections on a quarterly basis to reflect changes in the economy, attributed the changes to its most recent projections based on the drama that is sweeping across the economy and world markets.

"We think the economy will turn (for the worse) in the third quarter, and if that happens, we'll see a significant slowdown in IT spending in the fourth quarter and then the first and second quarters," said Andrew Bartels, a research analyst with Forrester Research.

It’s enough to make you want to slit your wrists. Does anyone out there have a blade?

Network World: Cisco to enter blade server market?

In a bulletin issued this week as a preview to Cisco’s Sept. 16 analyst conference, investment firm UBS states that Cisco is likely to enter the blade server market within a year. The firm cites “industry checks” as its source but did not say whether the company’s entry would be through acquisition or organic development….

…Cisco last year announced a $150 million stake in server virtualization software vendor VMware; unveiled an appliance to control pooled data center compute resources; and this year rolled out switches with increasing application intelligence and unified transport fabrics to gain more control over the source, destination and flow of data center traffic.

Blade servers are the next most obvious piece when it come to filling out this strategy, observers such as UBS note.

So, I guess it’s not all bad news for today.

Scalability is one of the more overused terms in networking – which makes it hard to explain why it’s important. Well, I mean, beyond the main concept of: “More scalability means you can hook up more computers to it!”

True, how big the deployment is probably the best way to objectively prove scalability – for example, NetQoS has one ReporterAnalyzer deployment monitoring over 20,000 WAN links. No small feat. But scalability isn’t just the quantity of computers hooked up to the box, but also how much of the quality of the data you maintain when you’ve got tons of computers hooked up to the box. Or to put it another way, scalability means that in even large deployments, you get all the data at high granularity.

Talking about scalability in pure device count is sort of like talking about network performance purely in terms of fault. It is possible to have poor scalability without having no scalability, when you sacrifice detail for device count.

Another key of scalability that many people don’t think about is performance of the device itself. It would be ironic to purchase a device to monitor network performance that had a very slow UI because it strained under the load of monitoring thousands of links.

One of NetQoS’s many accomplishments over the past six months has been getting a patent on a memory management method and system which allows us to manage hundreds of thousands of combinations in a very small memory footprint.

Memory management is a major part of scalability, because allocating memory during a programming operation is relatively expensive, in terms of operating processor resources, to allocate memory during runtime. Put another way: the more efficiently you use memory, the harder you can push the processor on other tasks. For this reason, scalability requires efficient memory usage.

In addition to our own products, we also use it in our integrations into Cisco Wide Area Application Services (WAAS) – we’re able to integrate code there with little impact to the host systems.

The Network Systems research group of the Max Planck Institute for Software Systems recently published a cool little online tool called Glasnost. It tests for BitTorrent traffic manipulation.

I’m not providing a link to the tool mostly because the institute – recently popular from Slashdot – seems to have been hijacked by malware that is causing pop-up windows to appear. Some of the pop-ups are pornographic – so I wouldn’t go checking out the site at work. Still, the basic idea is pretty damn cool.

In addition to testing for BitTorrent blocking, you can also get a pretty accurate bandwidth and latency reading. I have no idea if this program can be modified to keep WAN service providers honest and get a real measure of latency on a WAN, but the source code has been released to the public and anyone can use it.

But most people will just use it to check to see if their ISP does any BitTorrent traffic manipulation.

There is a bit of irony to the project as well; Glasnost is named after the well known economic and political reforms of Mikhail Gorbachev, the last General Secretary of the Communist Party and de facto last ruler of the Soviet Union. He opened up Russia to criticism from within.

The Planck Institute’s Glasnost has been gathering data on which ISPs are blocking or throttling BitTorrent transmissions. A copy of a map on which that data was plotted is found below – the black dots are tested connections that have no throttling, the red dots are tested connections that have throttling. I think I’ll just let the map speak for itself. (Click on the map for a larger version)

The raw numbers on the site confirm what is on the map. 889 total ISPs were tested. 14 of those had some sort of BitTorrent blocking. 10 of those were located in the United States. That’s 10 out of 199 – or a little over 5%.

The only other countries that have any sort of BitTorrent blocking ISPs are Canada (1 out of 99), Ireland, (1 out of 7), Malaysia (1 out of 2), and Singapore (1 out of 6). All the countries that were part of the former Soviet Union, and tested, came out with no blocking whatsoever.

Glasnost seems to be an appropriate name.

One of the things in IT that baffles me is the intense emphasis on security.  Don’t get me wrong, I can understand the psychology of it.  We, as human beings, fear loss more than we appreciate gain. 

But security seems to be one of the primary overriding concerns of networking, with entire magazines, trade publications, etc. devoted to the subject of locking down your network tighter than a snare drum.  It’s not surprising that these things exist.  What is surprising is the sheer number and percentage of “mindshare” that security takes up in IT. 

And even security professionals are beginning to notice this – and the “security fatigue” which is settling in.  Bruce Schneier at Wired writes about his experience at the RSA Conference, the largest information security conference in the world, in “Prediction: RSA Conference Will Shrink Like a Punctured Balloon.”

Talk to the exhibitors, though, and the most common complaint is that the attendees aren't buying….

No one wants to buy security. They want to buy something truly useful -- database management systems, Web 2.0 collaboration tools, a company-wide network -- and they want it to be secure. They don't want to have to become IT security experts. They don't want to have to go to the RSA Conference. This is the future of IT security.

There are something like 800+ IT security vendors out there, and they fill the market with gobs of confusing variations of messaging.

I asked him whether he walked through the show floor, looking at the company's competitors to see if there was any benefit to switching.

"I can't figure out what any of those companies do," he replied.

The people making purchasing decisions are less interested in the details and more interested in what the product will enable them to do.  It doesn’t mean security isn’t important to buyers.  It just means that they don’t want to have to think about security as a separate idea.  They want products with utility – that are also secure. 

There are many other industries where security is a big part of the business – and yet, security remains taken for granted.  Banking – the walk-in kind, not the online kind – is one of them.  When you deposit money in a bank, you know that they’ll keep your money in a big safe that presumably can’t be picked with a bobby pin.  (If the bobby pin is being wielded by a spunky team of “spunky girl adventurers,” however, all bets are off.) 

But what you’re not interested in who made the lock, how many pounds of pressure it can withstand, whether it’s steel, titanium, an alloy, and the component makeup.  You’re interested in what it can do – interest.  The bank is interested in what it can do with your money – lend it out and charge interest. 

You can have an extremely secure network that doesn’t actually do much, and focusing on security without focusing on the core competencies and getting more done with the information you have seems to be a bit of a  “biggest lock on an empty chest” mentality.

Recently, there’s been some discussion on Slashdot regarding MySQL in the past few months, after MySQL (the company) was bought out by Sun Microsystems.  MySQL (the company) has announced that they will be developing some proprietary add-ons to the backup capabilities of MySQL (the database) which will only be available to MySQL’s (the company’s) customers of MySQL (the database) enterprise edition, and not to MySQL (the database) community edition. 

This has been blown a bit out of proportion.  (The headline, on Slashdot, “Sun may begin close-sourcing MySQL” was misleading at best).  We e-mailed Steve Curry at MySQL (the company) and he pointed us to some information clearing up the situation.

· Anything that has been released as open-source under GPL continues to be released as open-source under GPL. Sun and MySQL (the company) are not going to start “closing” the open-source MySQL (the database,) and it seems unlikely that they will be able to legally do so even if they wished to.

· Improved backup capabilities are being planned in MySQL (the database) 6.0 for both the open-source community and open-source with proprietary add-ons enterprise version. 

· Proprietary add-ons are being added to the Enterprise version of MySQL (the database).  These add-ons are not core critical, they are essentially added-value for paying customers, which add compression, encryption, specific native drivers – things that a particular business might need but which aren’t critical to the core functioning of MySQL (the database.) 

· The decision to do so was done before MySQL (the company) was acquired by Sun Microsystems. If anything, Sun has been very open-source friendly, with Star Office forming the basis of OpenOffice.org, and Solaris and Java both open-source now.

· There is nothing preventing people from forking the MySQL (the database) source code and producing open-source versions of the proprietary capabilities.

The use of proprietary add-ons to an open-source system isn’t even all that rare.  Click N’ Run for Linux systems adds proprietary software to the open-source Linux; MacOSX is based on the BSD-licensed Darwin, a BSD-like distribution.

We also note the irony of a number of proprietary Web applications running off of LAMP stacks, where the L, the A, the M (the DB) and the P are all “free software.” 

There are a number of proprietary Web applications running with MySQL (the database) – and a move to “close source” MySQL (the database) would have messed with the business models of many companies – including NetQoS.  NetQoS uses MySQL (the database) Enterprise edition in our network monitoring and reporting products and we’re customers of MySQL (the company).  So we’re glad this whole thing is a tempest in a teapot. 

I tried to think of a prominent case where someone successfully “closed the source” of a flagship product after it was open-sourced - but couldn't until I went much, much farther afield.  There is a company “closing the source” on its major flagship product.

That company is Wizards of the Coast, a subsidiary of Hasbro.  And the flagship product is “Dungeons and Dragons.” 

Wizards (the company) makes Dungeons and Dragons, a role-playing, computer-less tabletop game where you play knights, elves, and powerful wizards (the characters) – a game that has a history of being very attractive to the technology-oriented crowd because of our love of math and power fantasies.

What makes Dungeons and Dragons particularly interesting is that a while back, Wizards (the company) released an “Open Gaming License” (OGL) which allowed third parties to develop additional content for Dunegons and Dragons, and, in fact, create entirely new games in different settings and genres using the rules established in Dungeons and Dragons 3^rd edition.  If you were a third-party company, you could publish supplements to provide traps, monsters, or new spells for wizards (the characters) to cast.  And many did.

This had numerous benefits all around; players needed to learn how to use only one system, and they had tons of D&D supplements to choose from, game companies found they had an audience in D&D players that they might not have otherwise had, Wizards (the company) found a sea of “developers” for their system which made ownership of D&D’s “core books” more valuable, and while it may not have resulted in a rebirth of the roleplaying game industry, it sure propped it up for a little while longer.

Because game players only had to learn one set of rules to play, the roleplaying game industry standardized quite a bit and the system used in Dungeons or Dragons (known as “d20”) became quite widely used, dominating the RPG field for a time. 

D&D “version 4.0” will soon be released, and many game beta testers believe the system has been radically overhauled and improved.  However, this new system will not be released under the OGL.  It will however, be released under the “Dungeons and Dragons 4^th Edition Game System License” (GSL). 

The GSL license has not yet been made public, but there are rumors, speculations, and concerns, fueled by online posts made by the brand manager and licensing manager for Dungeons and Dragons, and relayed by the lead writer of third-party publisher Necromancer Games that the GSL will contain a “poison pill” clause – that is, in order to use the GSL, a game company must not publish anything under the OGL.  

This would be like Microsoft saying that developers for Windows Vista are forbidden from publishing anything under the GNU public license.  And the upshot is now that developers have to choose between not developing games with the improved system or destroying their back-catalogs. 

Even if you don’t have a huge interest in D&D – in which case, I envy your normal social adjustment and relatively less awkward adolescence – it pays to keep up with this developing situation to see how a fight to close an open-source software product might actually go down.  Will Hasbro fail in its efforts to dominate the RPG industry, either shrinking their portion of market share or shrinking the size of the entire market?  Or will Hasbro succeed with this business plan, and the publishers of Monopoly (the game) end up with a de facto monopoly (the economic term) on this niche industry?

Update: On May 2, 2008, a week after this article's publication, Wizards of the Coast released an FAQ about the 4th edition licensing terms. The FAQ states:

Q. Can companies still produce 3.x products under the OGL?
A. Yes, but we anticipate that interest in the 4e GSLs will be greater.

Q. Can publishers release new products under both the OGL and 4E GSL?
A. No. Each new product will be either OGL or 4E GSL. If a new product is published under the 4e GSL, it cannot also be published as 3.x product under the OGL; and vice versa.

Q. I have multiple product lines. If I update one product line to 4th Edition, do they all have to be updated?
A. No. Publishers are able to choose on a product line by product line basis which license will work best.

Q. Will there be a different license for other lines, such as d20 Modern?
A. The d20 GSL will allow for other genres of roleplaying games.

Q. Why are there two different licenses?
A. The D&D 4e GSL is specific to the Dungeons & Dragons brand. The d20 GSL allows for non-fantasy genres. Both licenses tie to the 4th edition rule set.

Q. Do I have to give up my right to publish 3.5 OGL products in order to publish 4e compatible products?
A. No. Publishers are free to print product lines under either the OGL or 4E GSL. We would love to see our industry colleagues convert their entire product offerings to 4E, as we are doing, but we do not expect or require entire companies to convert to the new edition.

Q. Can publishers update their previous publications from older editions to the D&D 4th Edition rules?
A. Yes. Publishers participating in the Dungeons & Dragons 4th Edition GSL will be allowed, and encouraged, to convert their publications from earlier editions to the 4th Edition rules.

Kevin Davis, a senior consultant at NetQoS, will be presenting a few training sessions at Symposium about SuperAgent, the end-to-end response time module of the NetQoS Performance Center. This will include a training session about how to use time-based network metrics in troubleshooting.  He talks about his upcoming training session below.

In the session, I’m going to be covering the importance of using a time-based metric in troubleshooting, because end-users complain foremost about time.  For example, they’ll say “the application is running slow,” or they believe “the network is slow.”  To users, everything is based on time, that’s what they’re complaining about.  And they’re correct.

It’s very new to many people to think of performance in “time” although that may seem counterintuitive - because most people are used to reading utilization graphs.  With utilization graphs, however, we don’t know if 70 or 80 or 90 percent utilization is necessarily impacting the user experience.  I mean, we buy networking equipment, routers, switches, firewalls, servers, and we want them to be highly – or efficiently - utilized.  Seeing high utilization could indicate a problem – or it could just indicate that you haven’t over-purchased.  So you can have a link at 90% utilization or a router at ninety percent CPU utilization but you won’t know if that’s impacting the end-user without a time based metric.

It’s time-based data that tells you how the users are being impacted.  Sure, the utilization data – the interface utilization, memory utilization, I/O utilization, can often tell what is doing the impact.  But the time base shows you the degree of the impact – the real-world effect on end-users.  With a time-based instrument, such as NetQoS SuperAgent, you can find out where the delay increase is occurring, and whether it’s based in the network, server, or application. 

In fact, you can take a look at time-based data and make a determination very quickly as to which entity is creating the performance issue – the beautiful thing about SuperAgent, in particular, is that it trends by time 24/7, so not only can you determine how your important business applications are being impacted today, but you can go back and look at recurring patterns in performance issues.  You can see if today is worse than yesterday or last week or last month.

In the session, I’ll also be going over how to architect the data center for performance.  Placement of servers that participate in inter-architectures is critical for the health and performance of the application and indeed the data center.  We also talk about how different protocols, for example, Microsoft’s TCP/IP stack, can impact application performance by enhancing or degrading it. 

It’s important for servers that are serving the same application.  For example, a front-end Web server and a back-end Oracle database really should be on the same switch on the same VLAN.  That way they receive optimum service from the network.  If they do leave the switch, they’ll have to contend with bandwidth going up and down the switch links, and they’ll be switched and routed multiple times. 

Based on measurements from customer environments and from our own laboratories, when two servers are on different switches they can have up to 18 milliseconds delay between them.  If we think of that in the terms of network engineers of one millisecond per 100 miles, what in effect we’re doing when we put two different servers on different switches, or two different VLANs on the same switch, we’re making it look like those servers are 1800 miles apart – like one server is in Los Angeles and the other is in Memphis. 

Gerald Combs is the original author and lead developer of the open-source, multi-platform, Wireshark network protocol analyzer. Combs works for CACE Technologies – a company which makes products that compliment Wireshark.  Today he mostly takes care of the administrative parts of the project but still does development as well, and he controls the version numbers and release schedule.

After ten years of development, Wireshark finally reached the milestone of a 1.0 release.  We speak to Mr. Combs in an interview below: 

NPD: So what is Wireshark?

Combs: Wireshark is a network protocol analyzer.  It’s kind of a traditional analyzer in that it’s a GUI that has three panes, the top pane shows a list of the packets captured off the wire, the middle pane a detail of whatever packet you have selected, and the bottom page shows the actual hex output – the bytes in the actual output.

NPD: Why did you decided to build Wireshark?

Combs: Years ago, I worked at a small ISP in the Midwest, and unfortunately, they couldn’t get me a Sniffer, which was the standard analyzer at the time, and of the products out there that were available, none of them ran on the platforms we used at the ISP – namely Solaris and Linux.  So I decided to sit down one day and start writing my own analyzer. 

I did the first release in July of 1998, and soon after started getting a steady stream of contributions from a bunch of really smart people.  After that, we built up a pretty good following of users.  And right now, Wireshark is the world’s most popular network protocol analyzer. 

NPD: Why did you decide to open-source the project?

Combs: I’d used open source software for a long time at that point.  Before then, I worked at a university and we made a lot of use of open source software.  It just made sense to me.  I wanted to give back to the community and it just seemed like a good way to go.  As it turned out, it was a great way to go, because Wireshark is appealing for a lot of people who write code for it.

NPD: Why has it taken ten years to reach Version 1.0? 

Combs: I just wasn’t comfortable until recently putting out the 1.0 release.  I’ve known for years - shortly after we made the initial release, people started using it in production environments.  And some people had trepidation because it wasn’t 1.0 yet.  But for the most part, people just didn’t care about the version number and they used it wherever they wanted to and wherever they needed to. 

But for me there were a number of features that were crucial and missing until recently that prevented me from putting a 1.0 stamp on it.  Probably the last one, one of the main ones, was privileged operation on Linux – getting it so that you could capture as root but run the GUI as non-root user. 

NPD: Have people come up to you and told you about how Wireshark helped them out?

Combs: I get e-mails from time to time from people, saying that I’ve helped them out.  I have some former coworkers that have mentioned that.  It’s actually pretty encouraging. 

We get a huge amount of code each month.  Between each release, we have 200,000 and a million lines of changes.  That’s just changes.  The actual source code is about 1.5 million lines now.  That’s a bigger job than I can do individually.  And luckily there are a bunch of smart and talented people that can help me with that.

NPD: What was the greatest challenge in developing Wireshark?

Combs: The greatest challenge is just the day-to-day maintenance, keeping the project going.  But several years ago, we had an initial push of fixing security bugs a while back and it was a huge undertaking. I just remember spending several months doing nothing but fixing these security bugs, and it was a big chore.   We have a huge codebase now, and unfortunately we just don’t have the resources to audit that.  But we have a lot of automated processes in place like fuzzing and static analysis that help us find those bugs. 

I can’t say this enough: Thank you to all the Wireshark developers out there and the user team – this has just been a great journey and it’s one that I hope to continue. 

by Patrick Ancipink
Director of Product Marketing, NetQoS

There’s been a lot of growth (and attendant hype) in technology areas like WAN optimization and application acceleration over the past few years, and for good reason. Anything that helps companies speed up and reduce the risk of strategic IT initiatives like consolidating data centers, turning up new branches or serving an increasingly mobile and scattered user community will be popular.

To help with cope with the increasing reliance on the WAN and keep latency in check, there are a dizzying array of vendors and products out there – but if you’re trying to determine precisely which techniques and technologies to implement for your specific needs, the array of vendors quickly goes from “dizzying” to “disorienting” and finally “nauseating.” 

Cisco’s been in this Tilt-a-Whirl™ of a market for a while (and NetQoS has been right there with them) and they’ve taken some big steps recently to provide a more holistic approach that centers on building an “application aware” network, rather than trying to highlight one type of implementation against another for a narrow set of capabilities.

NetQoS started working exclusively with Cisco closely to help customers evaluate, measure, and prove the effectiveness of WAN optimization and application acceleration deployments. As customers are moving from pilot phases into full production, the before/after measurements and comprehensive monitoring are critical to ensure customers are getting the benefits they intended and doing what they need to deliver application performance. 

To help get the word out, Cisco just launched a new section of their web site today that contains a wealth of information about, as they call it, “WAN and Application Optimization.” The downloadable presentation, Cisco WAN and Application Optimization Technical Overview Presentation, puts Cisco technologies (and complimentary ones, NetQoS included) into a useful context with a methodical approach and framework built around four steps: Profile and Baseline, Optimize, Evolve, and Operate. A whole Campbell’s Factory of Cisco alphabet soup technologies are included—WAAS, ACE, NBAR, Netflow, CBQoS, IP SLA, PfR—to show how they work in concert and what role they play in the bigger picture.

There’s also the Cisco WAN and Application Optimization Solution Guide , a very in-depth publication—like 227 pages deep—that is targeted for “technical personnel involved in the specification, design, and implementation of specific WAN and application optimization solutions.” We, here at NetQoS, are proud to have contributed several sections to book regarding the methodology and implementation of network performance monitoring for WAN optimization and application acceleration. 

(If you are looking for some lighter fare, the video on the site tells a nice story in about 6 minutes including an airshow, snowmobiles, windsurfers, and skydiving—interesting choices for demonstrating the criticality of serving video over the WAN.  Then again, some company somewhere has to make the recreational products, I suppose.)