OpenFlow's architecture is inefficient, and caps performance while sucking unnecessary power.
That's the conclusion of a bunch of Comp. Sci boffins from researchers at Australian brain box Data61 and Sydney University, who assessed four major OpenFlow controllers – NOX, Maestro, Floodlight and Beacon. Their paper is at Arxiv.
Poor old OpenDaylight was also tested but not reported: “the performance [was] too low to provide any insightful comparison”.
To cut to the chase: none of the controllers tested got anywhere close to line speed, whether running on a network processor (based on Tilera chips), or on a Xeon E5-2450-based server (more on the configurations later).
On the CBench software defined networking (SDN) controller benchmark, the best the Tilera setup achieved was just under five million requests per second, compared to a line rate of 29 million requests per second.
It seems that Intel's long years of work understanding packet processing is paying off: on the x86 setup, Beacon was able to hit 20 million requests per second; the maximum of the other controllers was 7 million requests per second.
Line rate? Forget it: the CSIRO/Data61/Sydney Uni benchmark results
Since SDN controllers have to deal with traffic as flows (meaning they have to remember MAC addresses so as to track conversations, compared to an Ethernet switch that only has to know which port it's forwarding traffic to), network scalability is also a big problem.
None of the controllers stayed near their peak performance with 10 million unique MAC addresses in the benchmark, and the Java-based controllers (Beacon and Floodlight) stagger to a near-complete halt at that scale.
The problem, the paper says, is that OpenFlow itself has architectural inefficiencies. The authors pick out serialisation; I/O threading; and, “the key data structure of the learning switch application: the hash table”.
Serialisation is by far the biggest overhead: even the most efficient controller “spends a fifth of his time in packet serialisation … this limitation is inherent to the object oriented design principle of these controllers. They all treat each single packet as an individual object, a limitation that induces an unaffordable per-packet overhead.”
The authors' proposal is for a new SDN controller design: “treat arriving packets with pre-allocated buffers rather than new objects,” they write. Controllers should also “be aware of the hardware characteristics to limit cache misses on multi-core platforms, or exploit the network-on-chip on many-core platforms”. ®