Why one reader says there will be no "Intel Inside" of networking
Dear Vorticians,
A couple of entries back, I wrote about a company called Bivio, which is building what it claims is a general-purpose processor for network gear that would free developers to focus on value-added capabilitiies in software rather than having to design and build new hardware when customer needs change. It's an ambitious goal and I asked readers to weigh in on its feasibility. Vortician Jeff Prince, the chairman and CTO of ConSentry Networks, which is in the increasingly hot network access control market (more on that in an upcoming report), offered this cogent analysis.
"John, I read your latest Vortex Digest, and the topic was related to Bivio and their general purpose hardware for developing networking products of the future. You asked for opinions, so here's mine. First, a little history. During the upturn in the late 90's, a number of startups based their entire company strategy on very complex, custom ASICs (application specific integrated circuits) and built significant value on the performance benefits that these ASICs created. After the downturn, there was reluctance by the venture community to invest in network companies that wanted to develop their own silicon due to the capital required to fund them. So most of the startups that were funded were building products solely based on off-the-shelf hardware. Given this backdrop it is easy to see how common platforms were born.
"The networking world has changed for the better with the introduction of merchant silicon from companies like Broadcom and Marvell focusing on Ethernet connectivity, which has become a commodity market. At Foundry Networks, our first products were completely ASIC-based, 13 custom chips to build a switch. Today networking companies can be much more targeted at the areas that they want to innovate in, and use merchant silicon for those functions that they don't. Now for Bivio..
"I applaud Bivio for their vision and I expect some interesting products to result from their common platform. But the truly game-changing network technologies will come from the companies that make the proper tradeoffs between what is put in hardware and what is put in software. And while I completely agree with Elan Amir that the demands of the network are changing, resulting in a complete rehash of what is done in hardware and what is done in software, you can't take away my option to choose what hardware functions I can use to accelerate my software. They are tightly coupled.
"There is clearly an element of time-to-market in developing a networking product. I think Bivio will enable a certain class of products to be developed much more quickly than they could in the past, especially for companies that lack core competency in hardware. But in all my years of engineering, the development exercise has always been a tradeoff of time-to-market, performance and cost. And it's a zero sum game. I can't gain in time-to market without losing performance or cost. I can't imagine trying to build a product without full control of all three aspects. My assertion is that common platforms can thrive in markets where performance and cost are less important than product timing. Products developed for the LAN do not fall into this category. The LAN has performance levels that are beyond the one-size-fits all platforms.
"Here's another way of putting it. You don't bring a knife to a gunfight. So if you plan to take on the leading networking vendors in their core competencies, you need to out-innovate and out-execute them. Taking away the ability to innovate in silicon absolutely hampers your ability to compete and win. Cisco and Juniper still have very substantial ASIC development teams, and as far as I'm concerned it's the reason they're still on top. The important point here is choice. Choice of what is put in software, what is put in hardware, what silicon is purchased and what silicon is custom built. That's how game-changing network products are built."
Thoughts, Vortician Amir? Thanks Jeff.
Back to Vortex Blog
Comments
Post a comment
