Failover and NetEqualizer: The Whys and Why Nots

April 9, 2008 — netequalizer

Do you want failover on your NetEqualizer or wondered why it’s not available? Let me share a story with you that has developed our philosophy on failover.

A long time ago, back in 1993 or so, I was the Unix and operating system point person for the popular AT&T (i.e. Lucent and Avaya) voice messaging product called Audix. It was my job to make sure that the Unix operating system was bug free and to trouble shoot any issues.

At the time, Audix sales accounted for about $300 million in business and included many Fortune 500 companies around the world. One of the features which I investigated, tested, and certified was our RAID technology. The data on our systems consisted of the archives of all those saved messages that were so important, even more so before e-mail became the standard.

I had a lab setup with all sorts of disk arrays and would routinely yank one from the rack while an Audix system was running. The RAID software we’d integrated worked flawlessly in every test. We were one of the largest companies in the world and we spared no expense to ensure quality in our equipment, and we also charged a premium for everything we sold. If the RAID line item feature was included with an Audix system, it could run as high as $100,000.

Flash forward to the future. We get a call that a customer has lost all their data. A RAID system had failed. It was a well-known insurance company in the Northeast. Needless to say, they were not pleased that their 100 K insurance policy against disk failure did not pan out.

I had certified this mechanism and stood behind it. So, I called together the RAID manufacturer and several Unix kernel experts to do a postmortem. After several days locked in a room, we found was that the real world failure did not follow the lab testing where we had pulled live disk drives in our lab. In fact, it failed in such a way as to slowly corrupt the customer data on all disk drives rendering it useless.

I did some follow up research on failover strategies over the years and discovered that many people implement them for political reasons to cover their asses. I do not mean to demean people covering their asses, it is an important part of business, but the problem is the real cost of testing and validating failover is not practical for most manufacturers.

Many customers ask, “If a NetEqualizer fails, will the LAN cards still pass data?” The answer is, we could certainly engineer our product this way, but there is no guarantee for fail safe systems.

Here are the pros and cons of such a technology:

1) Just like my disk drive failure experience, a system can fail many different ways and the failover mechanism is likely not foolproof. So, I don’t want to recreate history for something we cannot (nor can anybody) reliably real-world test.

2) NetEqualizer’s failure rate is about two percent over two years, which is mostly attributed to harsh operating conditions. That means you have a 1 in 50 chance of having a failure over a two-year period. Put simply, the odds are against this happening.

3) If a NetEqualizer fails, it is usually a matter of moving a cable, which can be easily fixed. So, if you, or anyone with access to the NetEqualizer, are within an hour of your facility, that means you have a 1 in 50 chance of your network being down for one hour every two years because of a NetEqualizer.

4) Customers that really need a fully redundant failover for their operation duplicate their entire infrastructure and purchase two NetEqualizers. These customers are typically brokerage houses where large revenue could be lost. Since they already have a fully tested strategy at the macro level, a failover card on the NetEqualizer is not needed.

5) For customer that is just starting to dabble, they have gone to Cisco spanning tree protocol. Cisco has many years and billions of dollars invested in their switching technology and is rock solid.

6) Putting LAN failover cards in our product would likely raise our base price by about $1000. That would be a significant price increase for most customers, and one that would most likely not be worth paying for.

7) Most equipment failures are software or system related. We take pride in the fact that our boxes run forever and don’t lock up or need rebooting. A failover LAN card does not typically protect against system-type failures.

So, yes, we could sell our system as failsafe with a failover LAN card, but we would rather educate than exploit fears and misunderstandings. Hopefully we’ve accomplished that here.

Posted in Bandwidth Monitoring, Commentary and Editorials. Tags: , , , . Leave a Comment »

Comcast Should Adopt Behavior-Based Shaping to Stay out of Trouble

March 28, 2008 — netequalizer

Well it finally happened…

As reported by the NY times :

SAN FRANCISCO — Comcast, the country’s largest residential Internet provider, said on Thursday that it would take a more equitable approach toward managing the ever-expanding flow of Web traffic on its network.

The cable company, based in Philadelphia, has been under relentless pressure from the Federal Communications Commission and public interest groups after media reports last year that it was blocking some Internet traffic of customers who used online software based on the popular peer-to-peer BitTorrent protocol.

As many of our ISP customers already know, we have been proselytizing that using layer-7 packet shaping is a slippery slope for any provider and it was only a matter of time before a large provider such as Comcast would be forced to change their ways.

Note: Layer-7 shaping involves looking at data to determine what it is. A technique commonly used to identify bit torrent traffic.


The NetEqualizer methodology for application shaping has been agnostic with respect to type of data for quite some time. We have shown through our thousands of customers that you can effectively control and give priority to Internet traffic based on behavior. We did not feel comfortable with our layer-7 application shaping techniques and hence we ceased to support that methodology almost two years ago. We now manage traffic as a resource much the same way a municipality would/should ration water if there was a shortage.

Customers understand this. For example, if you simply tell somebody they must share a resource such as water, the Internet, or butter (as in WWII), and that they may periodically get a reduced amount, they will likely agree that sharing the resource is better than one person getting all of the resource while others suffer. Well, that is exactly what a NetEqualizer does with Internet resources, albeit in real time. Internet bandwidth is very spiky. It comes and goes in milliseconds and there is no time for a quorum.

We’ll keep an eye on this for you. If you are interested in learning more about how our technology differs from application-based shaping, the following link is very useful:

http://www.netequalizer.com/Compare_NetEqualizer.php

Posted in Commentary and Editorials. Tags: , , , , . 2 Comments »

APConnections a Model for Software Startups

April 9, 2007 — netequalizer

Art was recently asked by the prestigious Ewing Marion Kauffman Foundation to share his experiences as an entrepreneur on eVenturing.org. In his article, “Building a Software Company from Scratch,” Art shares some of the keys that have led to the success of the NetEqualizer and APConnections. Here’s the article:

Building a Software Company from Scratch

At APconnections, our flagship product, NetEqualizer, is a traffic management and WAN optimization tool. Rather than using compression and caching techniques, NetEqualizer analyzes connections and then doles out bandwidth to them based on preset rules. We look at every connection on the network and compare it to the overall trunk size to determine how to eliminate congestion on the links. NetEqualizer also prevents peer-to-peer traffic from slowing down higher-priority application traffic without shutting down those connections.When we started the company, we had lots of time, very little cash, some software development skills, and a technology idea. This article covers a couple of bootstrapping pearls that we learned to implement by doing.

Don’t be Afraid to Use Open Source

Using open source technology to develop and commercialize new application software can be an invaluable bootstrapping tool for startup entrepreneurs. It has allowed us to validate new technology with a willing set of early adopters who, in turn, provided us with references and debugging. We used this huge number of early adopters, who love to try open source applications, to legitimize our application. Further, this large set of commercial “installs” helped us ring out many of the bugs by users who have no grounds to demand perfection.In addition, we jump-started our products without incurring large development expense. We used open source by starting with technology already in place and extending it, rather than building (or licensing) every piece from scratch.Using open source code makes at least a portion of our technology publicly available. We use bundling, documentation, and proprietary extensions to make it difficult for larger players to steal our thunder. These will account for over half of development work but can be protected by copyright.

Afraid of copycats? In many cases, nothing could be better than to have a large player copy you. Big players value time to market. If one player clones your work, another may acquire your company to catch up in the market.

The transition from open source users to paying customers is a big jump, requiring traditional sales and marketing. Don’t expect your loyal base of open source beta users to start paying for your product. We use testimonials from this critical mass of users to market to paying customers who are reluctant to be early adopters (see below).

Channels? Use Direct Selling and the Web

Our innovation is a bit of a stretch from existing products and, like most innovations, requires some education of the user. Much of the early advice we received related to picking a sales channel. Just signup reps, resellers, and distributors and revenues will grow.

We found the exact opposite to be true. Priming channels is expensive. And, after we pointed the sales channel at customers, closing the sale and supporting the customer fell back on us anyway. Direct selling is not the path to rapid growth. But as a bootstrapping tool direct selling has rewarded us with loyal customers, better margins, and many fewer returns.

We use the Internet to generate hot leads, but we don’t worry about our Google ranking. They key for us is to get every satisfied customer to post somethig about our product. It probably hasn’t improved our Google ratings but customer comments have surely improved our credibility.

Honest postings to blogs and user groups have significant influence on potential customers. We explain to each customer how important their posting is to our company. We often provide them with a link to a user group or appropriate blog. And, as you know, these blogs stay around forever. Then, when we encounter new potential customers, we suggest that they Google our “brand name” and blog, which always generates a slew of believable testimonials. (Check out our Web site to see some of the ways they use testimonials.)

Using open source code and direct sales are surely out-of-step with popular ideas for growing technology companies, especially those funded by equity investors. But they worked very well for us as we grew our company with limited resources to positive cash flow and beyond.

Posted in Business Advice, News. Leave a Comment »
Newer posts »