KTH Logo

Our upcoming HotSDN ’14 paper: “ESPRES: Transparent SDN Update Scheduling”

Our paper titled “ESPRES: Transparent SDN Update Scheduling” will appear at HotSDN 2014 in Chicago. Peter Peresini will present the work. Here is the abstract:

Network forwarding state undergoes frequent changes, in batches of forwarding
rule modifications at multiple switches.  Installing or modifying a large number
of rules is time consuming given the performance limits of current programmable
switches, which are also due to economical factors in addition to technological
ones.

In this paper, we observe that a large network-state update typically consists
of a set of sub-updates that are independent of one another w.r.t. the traffic
they affect, and hence sub-updates can be installed in parallel, in any order.
Leveraging this observation, we treat update installation as a scheduling
problem and design ESPRES, a runtime mechanism that rate-limits and reorders
updates to fully utilize processing capacities of switches without overloading
them. Our early results show that compared to using no scheduler, our schemes
yield 2.17-3.88 times quicker sub-update completion time for 20th percentile of
sub-updates and 1.27-1.57 times quicker for 50th percentile.

Presentation at EWSDN 2013 on the proposed changes to the OpenFlow API

Peter presented our paper on the proposed changes to the OpenFlow API at EWSDN 2013. The paper itself is available here.The slides are also available

[db-video id=”y1ycninw”]

 

Software defined networks are poised to dramatically simplify deployment and management of networks.  OpenFlow, in particular, is becoming popular and starts being deployed.  While the definition of the “northbound” API that can be used by the new services to interact with an OpenFlow controller is receiving considerable attention, the traditional, “southbound”, API that is used to program OpenFlow switches is far from perfect.  In this paper, we analyze the current OpenFlow API and its usage in several controllers and show semantic differences between the intended and actual use.  Thus, we argue for making the OpenFlow API clean and simple.  In particular, we propose to mimic the process that exists in the Python community for deriving changes that result in a preferably only one, obvious way of performing a task.  Toward this end, we propose three OpenFlow Enhancement Proposals: 1) providing positive acknowledgment, 2) informing the controller about “silent” modifications, and 3) providing a partial order synchronization primitive.

Presentation at WRIPE 2013 on the ability of the network to compute

Peter presented our paper on demonstrating the ability of the network to compute at WRIPE 2013. The paper itself is available here. The slides are also available

[db-video id=”i9w2afb0″]

 

Ensuring correct network behavior is hard.  Previous state of the art has demonstrated that analyzing a network containing middleboxes is hard.  In this paper, we show that even using only statically configured switches, and asking the simplest possible question – “Will this concrete packet reach the destination?” – can make the problem intractable.  Moreover, we demonstrate that this is a fundamental property because a network can perform arbitrary computations.  Namely, we show how to emulate the Rule 110 cellular automaton using only basic network switches with simple features such as packet matching, header rewriting and round-robin loadbalancing.  This ultimately means that analyzing dynamic network behavior can be as hard as analyzing an arbitrary program.

Our upcoming HotSDN paper: “OF.CPP: Consistent Packet Processing for OpenFlow”

Our paper titled “OF.CPP: Consistent Packet Processing for OpenFlow” will appear at HotSDN 2013 in Hong Kong. Peter Peresini will present the work. Here is the abstract:

This paper demonstrates a new class of bugs that is likely to occur in enterprise OpenFlow deployments. In particular, step-by-step, reactive establishment of paths can cause network-wide inconsistencies or performance- and space-related inefficiencies. The cause for this behavior is inconsistent packet processing: as the packets travel through the network they do not encounter consistent state at the OpenFlow controller. To mitigate this problem, we propose to use transactional semantics at the controller to achieve consistent packet processing. We detail the challenges in achieving this goal (including the inability to directly apply database techniques), as well as a potentially promising approach. In particular, we envision the use of multi-commit transactions that could provide the necessary serialization and isolation properties without excessively reducing network performance.