A Report on NSDI'13: Composing Software Defined Networks

Updated on 2013-04-11. This is a report of the presentation done by Joshua Reich on 2013-04-03. Paper co-authors are Christopher Monsanto and Joshua Reich, Princeton University; Nate Foster, Cornell University; Jennifer Rexford and David Walker, Princeton University. Paper received Community Award.

Do you want to build a robust, large, complex network system using OpenFlow? Fine, you can do it -- but it is going to be cumbersome, time-consuming, and even error-prone. In a brief example, Joshua Reich described how complex it is currently to implement even simple sequential composition of logic such as simple load balancing and routing functions. The problem is that existing platforms for network programming only expose part of the network, lacking proper support for enabling the programming of various aspects in an integrated fashion. Building network applications using existing frameworks is pretty much like building complex software using assembly language, he said.

It was after drawing such a picture of the current state-of-the-art that Joshua presented Pyretic, a modular and intuitive language (and system) for enabling network programmers to build sophisticated network traffic management applications. Pyretic approaches the problem of designing complex network traffic management applications by providing three abstractions to programmers: policy abstraction, network abstraction, and packet abstraction. The first one enables programmers to use composition operators (sequential and parallel), which opens the door for doing all sorts of functional composition. The network abstraction lies on top of that, enabling programmers to decompose network software logic based on topologies. Finally, the packet abstraction provides extensive headers, which form the foundation for the previous abstractions.

Along the talk, Joshua navigated through a series of examples that highlighted the potentialities provided by each kind of abstraction -- which now enables network programmers to focus on the meaning of their applications, instead of concentrating on low level details. "One single line, absolutely precise", he said. He also emphasized that Pyretic captures the full power of OpenFlow, by providing one high level policy for each natively supported policy, and that Pyretic can be used to implement both static and dynamic policies -- a MAC-learning example described the power of these policies. Joshua concluded his technical discussion by sketching the implementation of the topology abstraction function in the context of a one-big-switch transformation example. Finally, he encouraged the audience to experience the full power of Pyretic by referring to the project website: http://www.frenetic-lang.org/pyretic.

The paper and presentation really caught the audience's attention! Srimat Chakradhar (NEC Labs Princeton) asked about the things one can do with OpenFlow but cannot with Pyretic. Joshua responded they did not find any limitations regarding this aspect. In terms of capabilities, Joshua does not think there is anything one can implement with OpenFlow but not with Pyretic, though he noted that what one does give up is the ability to finely manage table resource usage -- much in the same way that a Java programmer can no longer mange physical registers and memory. Chakradhar also asked about impact on end-to-end latency. Joshua replied that the current prototype is mostly an interpreter, but that the micro-flow compiler that will be released shortly one would have the same performance. Rajesh Nishtala (Facebook) asked about the impact on queuing behavior. Joshua responded that they haven't yet done this testing, but expect performance comparable to other systems.