The SDN meetings have definitely kicked up in attendance (nothing like a $1.3bn acquisition to peak interest!). At the SDN track that’s part of the Ethernet Summit that Matt, Roy and I have participated in for some time, the crowds and content were both up. I again got to chair the closing forward-looking panel, this time with CTO’s from Cisco, Brocade and IBM, as well as a couple of CEO’s thrown in for good measure.

David Ward (Cisco Engineering CTO) and I got into an interesting dialog about the interactions of applications and networks.  David has been talking a lot about how Cisco’s onePK will lead to increased visibility into how applications use networks by leveraging all the data that is available within today’s Cisco devices just waiting to be liberated (I personally believe that data visibility is always unexpectedly valuable).

David’s comments brought to mind a remarkable observation that Peter Deutsch had made in 1994 about the “Fallacies of Distributed Computing:” (1) The network is reliable, (2) latency is zero, (3) bandwidth is infinite, (4) the network is secure, (5) topology doesn’t change, (6) there is one administrator,, and (7) transport cost is zero. The fact of the matter is almost 20 years later most programmers are just as ignorant about network reality, leading to my question: do you really want such people making meaningful assertions about how the network should operate?

The discussion suggested some useful steps we should take based on increased network visibility that are far simpler and less scary than encouraging programmers to configure the network. In the case of disk drives, programmers understand that data in memory is different from data on a disk, to data retrieved from a complex database system, that data that has to be fetched from somewhere on the internet is different still, and that an application design needs to reflect those differences. I suspect that when we start measuring how actual programs use actual (or virtual) networks we can identify a comparably small number of typical network use cases and understand much better how actual network performance also has to be reflected in a program. Perhaps as a result, these different network use categories can be made explicit in modern application design (or in high level network-utilizing program abstractions) and the applications needs communicated to the network in that fashion.

The next huge “baby” step could be monitor network use by a specific application and build an operating baseline, after which anomalous application behavior or network performance could be flagged. Actual network usage would also give orchestration systems useful information for provisioning and workload movement.

Maybe we don’t really need to program the network; maybe a little visibility will go a long way especially given where we are coming from….