I keep hearing about how SDN will fail because of high round-trip latency from an switch or router platform to the controller. This is much like the criticism I heard about TCP performance in the mid-1980s. My first TCP throughput performance test using TTCP between a VAX 780 running BSD Unix and a Sun workstation showed 30KB/s (yes, Kilobytes per second!) It was only after Van Jacobson started researching TCP performance that we started to see improvements in throughput. Today, TCP is able to scale from dialup to long, fat pipes.
The same types of performance improvements are possible with SDN systems. A good example is the research on controller performance (http://www.rob-sherwood.net/sdnperf.pdf). The primary change was to implement multi-threading and I/O batching. The improvements were quite significant: a 33-fold improvement in response time. The authors note that the improvements were just the simple ones that could be quickly and easily implemented. The point is that there is a lot of room for significant improvements in SDN controller performance.
Distributing the SDN controller function across multiple hardware platforms will help make sure that controllers are near the switches in order to minimize the request/reply latency. Intelligent location of controllers in the network is something that we’re going to have to learn. I’m sure that there will be one or two important performance-related rules of thumb that will be developed as we gain more experience with SDN network design.
Critics are correctly pointing out a weakness in SDN. However, we will learn how to overcome this weaknesses, at least to the extent that it allows us to take advantage of the benefits that SDN provides. We just need to instrument the system so that we can collect the data necessary for us to understand the limitations and learn how to work around the problems that we find.
-Terry