Skip to content

Presentation at PAM ’15 on OpenFlow switch differences and performance characteristics

At the Passive and Active Measurements Conference (PAM) 2015 in New York, Maciej presented our paper on detailed measurements of OpenFlow switch differences and performance characteristics.

The abstract is as follows: SDN deployments rely on switches that come from various vendors and differ in terms of performance and available features. Understanding these differences and performance characteristics is essential for ensuring successful deployments. In this paper we measure, report, and explain the performance characteristics of flow table updates in three hardware OpenFlow switches. Our results can help controller developers to make their programs efficient. Further, we also highlight differences between the OpenFlow specification and its implementations, that if ignored, pose a serious threat to network security and correctness.

Presentation at CoNEXT ’14 on providing reliable rule installation in software defined networks

Maciej presented our paper on the proposed transparent layer that relies on control and data plane measurements to confirm SDN (OpenFlow) rule updates only when the rule is visible in the data plane. The paper itself is available here.

[db-video id=”c3rmil0f”]

Our upcoming CoNEXT ’14 paper: “Providing Reliable FIB Update Acknowledgments in SDN”

Our paper titled “Providing Reliable FIB Update Acknowledgments in SDN” will appear at CoNEXT 2014 in Sydney. Maciej Kuzniar will present the work. Here is the abstract:

In this paper, we first show that transient, but grave problems such as violations of security policies can occur with real switches even when using consistent updates to Software Defined Networks. Next, we present techniques that are effective in ameliorating this problem. Our key insight is in creating a transparent layer that relies on control and data plane measurements to confirm rule updates only when the rule is visible in the data plane.

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.