Do It Again Part 3: It is Easy to Believe in Self-Referential Data Sets

A component of my job requires me to interview people and one effect of the successful Arista IPO has been an increased number of CVs from Cisco employees. I am interviewing a candidate from Cisco about a week ago and this person tells me that Plexxi seems to have copied the theme from Insieme. That is nice. I find it to be a good exercise to look back and review writings from a year or two ago. Is it still accurate? What has changed? Do you still believe what you wrote? I think this is best way to avoid self-referential data sets.

Here are few things I wrote on this blog:

• April 2012 “Missing the Point About SDN.” Link here. (Written in a snarky tone, it is still valid).

• October 2012 “Workload Placement Constraints.” Link here.

• December 2012 “Applications defining the construct, enabling the orchestrating and configuration of the network; that is a powerful concept.” Link here.

• January 2013 “Time to Change the Network Dialog; Traffic Patterns and Affinities.” Link here.

• March 2013 “It is all about Doctrine.” Link here. (Read that post if you want to know why SDN adoption has been slow and overhyped.)

• May 2013 “The Self Similar Nature of Ethernet Traffic.” Link here. (An alternative title could be The Reinforcement Nature of Self Referential Data Sets.)

Nothing that has happened in the past two years has altered my views in any significant way. If you pick you head up and look down the road there are all sorts of road signs that tell you we are going to be building very different networks over the next 10 years and these networks will not look anything like the networks from the 1990s.   Here are a few items I read in the past week:

• Cowen & Company Report “Fueling our ongoing belief that the risk to Cisco and other networking and communication equipment suppliers posed by software-defined networking (SDN) remains overstated, up front, at the beginning of a keynote address at LightReading’s “Big Telecom Event” conference in Chicago on 6/17/2014, Bikash Koley, the principal architect and manager of network architecture at Google, apprised an audience of communication industry participants that “SDN is not about cheap hardware. You are looking at the wrong thing if you are looking at SDN for cheap hardware.” To be fair, Mr. Koley’s observation does not negate the SDN risk to either Cisco or the larger networking equipment industry. As is well-known by now, Google has been a pioneer in its development and deployment of SDN and currently does not use Cisco switches in its network. And SDN development, Proof-of-Concepts, trials and deployments by an increasing number of organizations continues to advance as we heard, most recently, in presentations by Google and a number of other organizations at the conference. That said, we find Mr. Koley’s admonition particularly noteworthy given: Google’s pioneering SDN role; the significantly greater depth and breadth of Google’s networking resources compared to virtually all other organizations—our industry checks indicate that Google has over 900 networking engineers, including many of the best and brightest in the industry, a number of whom have PhDs; and what appears to be the ongoing widely held perception among the investment community that SDN will have a severely adverse impact on—specifically, the hardware business of—Cisco and much of the rest of the networking and communications equipment industry. And, in our view, it remains preciously early in the development and deployment of SDN, and accordingly, we believe it is still premature to predict both the timing and the substantive impact of SDN on Cisco and the larger networking and communications equipment industry.”

• “…left to the multicore path, we may hit a “transistor utility economics” wall in as few as three to five years, at which point Moore’s Law may end, creating massive disruptions in our industry. Hitting a wall from one of these two directions appears inevitable. There is a silver lining for architects, however: At that point, the onus will be on computer architects–and computer architects only–to deliver performance and efficiency gains that can work across a wide range of problems. It promises to be an exciting time.” Link to paper here.

• If we are at the end of CPU scaling, what does that mean for the network? Link here.

I have a clear view in my mind as to where the network is going and it often stands apart from the mainstream view. I think the impact of multi-threaded applications, power consumption growth, flash, etc. will require a vastly different network to be built and that turning point for that network is closer than most people realize. Simply turning the crank on the cost curve of the old network construct is not going enable a new generation of multi-threaded applications utilizing deep resource pools of compute and storage.

/wrk