Wednesday, April 3, 2013

SDN confusion

I found the Monsanto et al. paper (Composing Software Defined Networks) fascinating, in part because it forced me to continue confronting how little I "get" about software-defined networking. I'm grateful to Aditya Akella for his very readable public summary for non-experts -- this is a great innovation that I hope NSDI continues and other conferences adopt.

Two things about this paper stuck out for me:
  1. The suggestion that the authors have outgrown the OpenFlow interface, and in order to implement Pyretic they needed a controller-maintained mapping layer on top of OpenFlow:
    Ideally, OpenFlow switches would support our extended packet model directly, but they do not. Our run-time system is responsible for bridging the gap between the abstract model and the OpenFlow-supported packets that traverse the network. It does so by generating a unique identifier that corresponds to a unique set of non-OpenFlow-compliant portions of the packet (i.e., all virtual fields and everything but the top of the stack in an OpenFlow-compliant field). This identifier is stored in spare bits in the packet. [Any source of spare bits (e.g., MPLS labels) could be used. Our current implementation uses the VLAN field.] Our run-time system manages a table that stores the mapping between unique ids and extended data.
    To this non-expert, that raises a bunch of questions. To what extent does OpenFlow draw the boundary between hardware- and software-defined networking in the right place, to enable this kind of high-end research into elegant abstractions? If every configuration of virtual fields is a totally separate flow as far as the switch is concerned, what are the performance implications of requiring the switch to query the controller and maintain an entry for each separate "flow"? The VLAN field is only 12 bits -- surely this constrains the complexity of the flows or the rules that can exist on the network? The state could be enlarged another 20 bits by adding in the MPLS label field, but is it realistic to have 2^32 flow table entries in the switch anyway?

  2. The paper highlights an "interesting twist" (sec. 5.2) that "the correct processing order of load balancer and firewall turns out to be direction-dependent." In other words, incoming packets need to be firewalled and then load-balanced, while packets headed in the opposite direction need the same steps to be un-applied in the opposite order. The example application solves this with a conditional check:
    fwlb = if_(from_client, afw >> alb, alb >> afw) 
    But naively, shouldn't it be "obvious" that if we compose a load-balanced service inside a firewalled subnetwork, the order that transformations are applied for incoming packets must be reversed when those same transformations are removed from outgoing packets? This is the case any time we invert the composition of two functions! Given that the authors here are proposing a new and powerful system of high-level abstractions, why should the programmer have to worry about this detail explicitly?

    I think the issue may be that this paper is not about the composability of networks (whose gateways may apply transformations and enforce rules), but about the composability of packet-processing policies. But I am not, frankly, very sure I really got it. There may be considerable subtleties abound as the SDN folks continue searching for the right abstractions to elegantly control the behavior of large networks.