Throughout much of last year, Scott Shenker delivered a presentation that is considered a seminal touchstone in software-defined networking. The presentation is called “The Future of Networking, and the Past of Protocols,” and an early version of it can be viewed here, though later iterations also are available online.
Shenker is a co-founder and chief scientist at Nicira Networks. He also is holds the title of Professor of Electrical Engineering and Computer Science at the University of California, Berkeley. Along with Nick McKeown and Martin Casado — the other co-founders of Nicira — he is widely regarded as a thought leader in the SDN community. (There are SDN intellectual luminaries beyond Nicira’s walls, but it’s notable that these three have combined their talents under one corporate roof.)
Technology is Easy, People Are Hard
In this post, I want to summarize a few salient thoughts featured in Shenker’s presentation. I will refer to these ideas in subsequent posts (well, at least one, anyway) that explore the commercial potential and the cultural challenges SDN might face in an enterprise world, where — pardon the paraphrasing of the legendary showbiz quote attributed to Donald Wolfit — technology is easy, but people are hard. (Nicira probably knows as much, which is why it is targeting cloud service providers rather than enterprises, at least for now.)
In his presentation, Shenker starts with an academic paradox based on his experiences as a professor at UC Berkeley. He says his colleagues who teach operating systems or databases provide instruction on fundamental principles, such as synchronization and mutual exclusion. Conversely, when he teaches introductory networking, he teaches his students about a “bag of protocols.” There are no real principles in networking, he argues.
Beyond academia, in the realm of the practical and quotidian, Shenker notes that computation and storage have been virtualized and have become flexible and easy to manage, but “not so much with networks,” where protocol complexity reigns.
Masters of Complexity
He then asks why the intellectual foundations of networking are so weak, and wonders how those foundations can be made stronger. Shenker explains that networks were simple and easy to mange initially, starting off with straightforward Ethernet and IP designs. New control requirements resulted in complexity. He says ACLs, VLANs, traffic engineering, middleboxes, and deep packet inspection have complicated what was an elegant architectural design.
Network infrastructure still works, Shenker says, because the networking industry and its professionals are masters of complexity. Unfortunately, the ability to master complexity is a mixed blessing. Complex systems typically are built on weak foundations. The systems are complex because the foundations are weak, and the networking industry has become adept at treating the symptoms rather than curing the disease.
He points out that good user interfaces are not produced by masters of complexity, noting that the ability to master complexity is very different from the ability to extract simplicity. (He tells an amusing anecdote on this theme hearkening back to his time at Xerox PARC.) Moreover, when one masters complexity, one has to do it for every single problem. When you extract simplicity, the benefits last longer and can be applied more broadly.
Shenker examines how computer programming was simplified over time. He looks at how useful abstractions were defined and evolved to extract simplicity and make programming tasks easier. Abstractions shield users from low-level details.
While abstraction has been at the center of much work in computer science, Shenker explains that has not been true in networking. He says abstractions have been addressed in layers that provide data-plane service abstractions, as exemplified by IP’s best-effort delivery and TCP’s reliable byte stream. These abstractions convey ideas about what the network can do for us, but Shenker says they’re terrible interfaces because they violate the principle of modularity. It works, he says, but it’s based on bad system-design decisions.
At the control-plane, where useful abstractions do not exist, Shenker says SDN’s goal is to break the bad habit of adding to network complexity. Networking addresses control issues today by defining new protocols, such as for routing, or by designing a new ad-hoc mechanism, such as for traffic engineering; or it leaves the problem to be addressed by manual operator configuration, as is done with access control and middleboxes.
He then looks at how such modular abstractions can be applied to network controls. It’s all about applying abstractions to simplify control tasks relating to forwarding models, distributed state, and detailed configuration.
In SDN, the forwarding model shields the above layers from the particular low-level forwarding design, which could involve possibilities such as a general x86 program, MPLS, or OpenFlow.
OpenFlow: Good Enough for Now
On OpenFlow, Shenker later in his presentation offers the following:
“OpenFlow is one possible solution (as a configuration mechanism); it’s clearly not the right solution. I mean, it’s a very good solution for now, but there’s nothing that says this is fundamentally the right answer. Think of Open Flow as x86 instruction set. Is the x86 instruction set correct? Is it the right answer? No, It’s good enough for what we use it for. So why bother changing it? That’s what Open Flow is. It’s the instruction set we happen to use, but let’s not get hung up on it.”
As for state distribution, Shenker said the control program should not have to deal with the vagaries of distributed state. An abstraction should shield the control program from sate dissemination/collection. A network operating system can provide that abstraction, delivering a global view of the underlying network.
The control program will operate on this network view, which is essentially a graph, providing input on required device configuration across the network.
Three Basic Interfaces
In Shenker’s view, there are three basic network interfaces tied to SDN abstractions. There’s the forwarding interface, which provides a flexible, abstract forwarding model; there’s the global network view, which shields higher layers from state dissemination/collection; and there is the abstract network view, which shields the control program from details of the physical network.
He points out that these abstractions “are not just academic playthings.” They change where we focus our attention and thus enable much greater functionality from less effort. As a result, there will be no more need to design distributed control protocols. Instead, you would define control programs (applications) over an abstract model. Writing control programs becomes about what you want to have happen, not how to make it happen.
Bringing the presentation full circle, and reconciling it neatly with its title, Shenker contends that the future of networking lies in cleaner abstractions, not in the ongoing definition of complicated distributed protocols. As Shenker puts it, “the era of ‘a new protocol per problem’ is over.”
Networking definitely seems to be heading in the direction Shenker envisages, but I’m not sure the old networking establishment is prepared to bury its “bag of protocols” just yet. As Shenker himself has said, it takes years to internalize and evaluate abstractions. It might take longer for networking professionals — vendors and customers alike — to adjust to software-oriented network programmability.