Performances of OpenFlow-Based Software- Defined Networks: An overview <s> C. Multithreading-Based Improvements <s> Network architectures in which the control plane is decoupled from the data plane have been growing in popularity. Among the main arguments for this approach is that it provides a more structured software environment for developing network-wide abstractions while potentially simplifying the data plane. As has been adopted elsewhere [11], we refer to this split architecture as Software-Defined Networking (SDN). While it has been argued that SDN is suitable for some deployment environments (such as homes [17, 13], data centers [1], and the enterprise [5]), delegating control to a remote system has raised a number of questions on control-plane scaling implications of such an approach. Two of the most often voiced concerns are: (a) how fast can the controller respond to data path requests?; and (b) how many data path requests can it handle per second? There are some references to the performance of SDN systems in the literature [16, 5, 3]. For example, an oft-cited study shows that a popular network controller (NOX) handles around 30k flow initiation events1 per second while maintaining a sub-10ms flow install time [14]. Unfortunately, recent measurements of some deployment environments suggests that these numbers are far from sufficient. For example, Kandula et al. [9] found that a 1500-server cluster has a median flow arrival rate of 100k flows per second. Also, Benson et al. [2] show that a network with 100 switches can have spikes of 10M flows arrivals per second in the worst case. In addition, the 10ms flow setup delay of an SDN controller would add a 10% delay to the majority of flows (short-lived) in such a network. This disconnect between relatively poor controller performance and high network demands has motivated a <s> BIB001 </s> Performances of OpenFlow-Based Software- Defined Networks: An overview <s> C. Multithreading-Based Improvements <s> OpenFlow is currently the most commonly deployed Software Defined Networking (SDN) technology. SDN consists of decoupling the control and data planes of a network. A software-based controller is responsible for managing the forwarding information of one or more switches; the hardware only handles the forwarding of traffic according to the rules set by the controller. OpenFlow is an SDN technology proposed to standardize the way that a controller communicates with network devices in an SDN architecture. It was proposed to enable researchers to test new ideas in a production environment. OpenFlow provides a specification to migrate the control logic from a switch into the controller. It also defines a protocol for the communication between the controller and the switches. As discussed in this survey paper, OpenFlow-based architectures have specific capabilities that can be exploited by researchers to experiment with new ideas and test novel applications. These capabilities include software-based traffic analysis, centralized control, dynamic updating of forwarding rules and flow abstraction. OpenFlow-based applications have been proposed to ease the configuration of a network, to simplify network management and to add security features, to virtualize networks and data centers and to deploy mobile systems. These applications run on top of networking operating systems such as Nox, Beacon, Maestro, Floodlight, Trema or Node.Flow. Larger scale OpenFlow infrastructures have been deployed to allow the research community to run experiments and test their applications in more realistic scenarios. Also, studies have measured the performance of OpenFlow networks through modelling and experimentation. We describe the challenges facing the large scale deployment of OpenFlow-based networks and we discuss future research directions of this technology. <s> BIB002
Authors in BIB001 attempt to understand the implication of using multi-threading techniques in SDNs. They have introduced a new multi-threaded controller called NOX-MT (new release of the NOX OpenFlow controller). The main conclusion is that NOX-MT improves the controller throughput by more than 30 times. Indeed, NOX-MT takes full advantage of multi-core processors using multithreading techniques that can run multi-tasks concurrently and handling different tasks at the same time, hence making optimal use of the available resources. An important study that investigates the impact of multithreading on performances is given BIB002 . The authors perform a comparison between different controllers in term of performance, especially the throughput. In fact, two major factors distinguish controllers, the first one is the algorithm of distributing incoming messages between threads, and the second one is the mechanism or the libraries used for network interaction. Using different number of threads (from 1 up to 12) shows that single threaded controllers (Nox and Ryu) are very limited regarding the throughput because they cannot handle a large number of flows, however the Beacon controller which is multi-threaded can handle a large number of flows per second. Knowing that Python controllers (POX and Ryu) do not support multi-threading, they show no scalability despite a number of CPU cores. Maestro's scalability is limited to 8 cores as the controller does not run with more than 8 threads. The performance of Floodlight increases steadily in line with the increase in the number of cores. Finally, Beacon achieves a throughput of nearly 7 million flows per second and shows the best scalability. From the previous studies, we conclude that the characteristics and performances of SDN controllers may be very different. So, it's important to carefully choose the OpenFlow controller. At the end of this section, we give a summary of some famous controllers and their characteristics in the table 1. In particular, we specify the OpenFlow version that they support, their throughput, if they are multi-threaded or not, if they can be distributed or not (distributed controllers will be considered in the next section). Also we classify all controllers by their ability to support OpenStack, which is an open source platform for creating and managing public or private cloud.