As the author of the cbench tool used in this paper and as CTO of a company that sells commercially supported SDN controllers, I felt like I should jump in here and clarify a few things.
First, the paper's authors are looking at a very specific subset of SDN/OpenFlow architecture called 'reactive flow control' and their results do not apply for controllers that use other techniques, e.g., proactive flow control (check out http://www.bigswitch.com/blog/2014/06/02/modern-openflow-and-sdn-part-ii for more on the difference). It's been well known for a long time that reactive flow control is a bad idea and doesn't scale - that's why none of the commercially supported SDN solutions implement it. The authors should be careful to qualify the limitations of their work so that people don't get the wrong idea. Certainly, plenty of SDN controllers have rock solid production use and scale-out design -- happy to provide customer success stories if folks have questions about this.
Second, when I wrote the cbench tool, I never intended it as a realistic data center work load generator, which this paper seems to believe it is. Cbench was intended to test various I/O subroutines of a controller (like the marshalling/unmarshalling speed that the authors identify). No one should ever assume that one controller design is better/more robust/more scalable than another because it comes up with a higher cbench score. Particularly once you move to the more robust proactive controller design, the cbench score become an irrelevant measure of controller scale.
If the authors of the paper would like to chat more about this or in general improve the quality of their research, please feel free to reach out to me directly.
- Rob Sherwood
.
Biting the hand that feeds IT
