Network World Blog missing the boat on Packeteer’s decline in revenue


The one thing bad about being a publicly traded company is that you cannot hide from your declining sales, in the following network world blog post and related comments ,the authors make some good points as to where and why they would choose Cisco Wan Optimization over Blue Coat and vice-versa. They also comment on all sorts of reasons why Blue Coat’s revenue in this area is declining , although they neglect one obvious reason.

Prices of bandwidth have fallen quite rapidly over the last 10 years. In some larger metro areas  Internet access runs for as little as $300 per month for 10 megabits. The same link 10 years ago would have run close to $5000 per month or more. Despite falling bandwdith prices,  WAN optimization solutions from the likes Blue Coat, Cisco and Riverbed, remain relatively high.  Many ptential WAN optimization customers will  simply upgrade  their bandwidth rather than invest in new optimization equipment.  You would think that vendors would lower their prices to compete, and they are to some degree; however the complexity of their core solutions requires a mimumum price floor.   The factors that create the price floor on equipment are related to, methodology  of the internal technology, and sales channel costs,  and unfortunately these fixed cost factors cannot keep pace with falling bandwidth prices .

Our prediction is that WAN optimization devices will  slowly become a commodity with automated reduced complexity. One measure of the current complexity is   all the acronyms being tossed around describing WAN optimization. The sales pitches filled with accronyms clearly corrolate that perhaps these devices are just too complicated for the market to continue to use. They will become turn key simple and lower cost or die. No player is bigger than the Market force of cheaper bandwith.

Related articles:

ROI calculation for packet shaping equipment

Does lower cost bandwidth foretell a decline in bandwidth shaper sales?

http://www.networkworld.com/community/comment/reply/46590

The birth of a new kind of new kind of Packet Shaper (NetEqualizer)


Today my attention was drawn to a forum thread about setting up queuing and bandwidth fairness on a Cisco Router. The techs in the discussion were obviously very familiar with Cisco and its internal programming language. Needless to say it was a very low level discussion and  to make any sense of it would require  sort a Cisco certification on the inner workings of their IOS programming language. The discussion reminded me of a conversation I had back in 2002 when the idea of turn key bandwidth controller popped into my head

In 2002  I was running a start up WISP with a partner. One issue that we saw coming was sharing bandwidth on a tightly contested T1. We decided it was worth looking into what was available, was there something we could just plug in to handle this and get on with our core business of  running the WISP.
My day job at the time was at Bell Labs, and just recently there had been quite  a few defections to Cisco.  So I  decided to tap some of more former coworkers to see if Cisco had anything turn key picked up the phone and asked a couple of peers what a Cisco box could do  support of some form of turn key fairness. ‘Well you can program the IOS bios queues bla bla” I had heard enough. It seemed that although it was definitely possible to do this with Cisco, I just wanted  something to plug  in and forget about it.  I did not have money to hire a Cisco tech and figured many other start up WISPS in my position were in the same boat. Little did I realize at the time, that the NetEqualizer would become an International hit, distributed across all industries (Hospitals, Cable Companies, Universities etc) around the world over the next 6 years.

The model  of how to approach this issue of fairness was already widely used  in the computer server world. Most people are not concerned with  fairness of processes or threads on web server or data base server? Why is that ? Most  modern computer servers  have some form of operating system that insures that the processes running don’t dominate the central processor (usually Linux). The basic idea is that a little timer that keeps track of a processors resources and how much a process has used if they HOG too much this timer kicks and allows others to get their turn.

The point of this story is there is no manual intervention needed, computers are so cheap that it would be absurd to pay somebody to do this, but that was not always the case. As late as 1986 the Main Frame computer dominated data processing, and with a main frame came a computer operator , a human who had the task of making sure jobs (as there were called) ran to completion in a timely manner,  as well as making sure tape drives were loaded etc.

Do you see the parallel here ? As computers became cheaper it was not economical to employ somebody to watch over this resource, the job still existed  but it was automated and incorporated into the operating system.

Flash forward to 2002, what my Cisco  freinds were  proposing was a labor intensive solution to managing a resource (bandwidth). So the idea was to take this one aspect of managing a network and essentially fire the operator (or the Cisco programmer) And so it was born an automated fairness device for sharing bandwidth and we have no looked back since.

Resources on computers and ways to handle this type of thing were invented back in the 70’s and became wide spread with the death of the card reader.

Editors note: CIsco is a fine product and perhaps there is some easy way to perform this function and I am just too stupid to understand.

%d bloggers like this: