Latency Tests

We test the responsiveness of the controller pool under varying loads by measuring the Round Trip Times of pings sent between the client and server. The flow rules in the switch have a hard-timeout of 1 second and the pings are spaced 2 seconds apart, ensuring that each new ping packet goes to the controller. Thus, the path of the Ping and response is client → switch → controller → switch → server →

switch→ controller →switch →client. This allows us to measure the additional latency the ping experiences due to controllers under heavy loads. We send 20 pings and find the average of the pings’ RTT (Round Trip Time). According to a recent study [186], the maximum tolerable latency for an interactive user based service such as voice communication is 150 milliseconds. We therefore set a maximum wait time of 150 milliseconds on the pings and all unresponsive pings are recorded as 150ms, indicating they have surpassed the maximum value. We perform these ex- periments using the Stock OvS and switches with both load distribution algorithms implemented. For each switch, we perform the ping test under controller loads of

between 500 and 5000 packets per second. We vary as well the size of the controller pool in each experiment and display the results in Figures 5.6 and Figure 5.7.

(a) Stock OvS (b) Round Robin Load Balancer

(c) Load Aware Load Balancer

Figure 5.6: Latency of Pings with multiple controllers (Homogeneous Controller Pool)

(a) Stock OvS (b) Round Robin Load Balancer

(c) Load Aware Load Balancer

Figure 5.7: Latency of Pings with multiple controllers (Non Homogeneous Controller Pool)

We first note that with the switch using either load distribution algorithm, in- creasing the controller pool size results in better response times from the pings, however regardless of the Homogeneous controller pool size, the Stock OvS registers

ping RTTs 5ms-16ms up to 1000pps but registers poor connectivity over 1000pps (Figure 5.6a). With one controller, a load of 1500pps or more quickly overwhelms the controller. Since the Stock OvS sends all requests to all controllers, this means that the responsiveness of the controller pool is only as good as its best controller which is capped at 1500pps here. Using the Homogeneous controller pool, the Round Robin approach which evenly distributes the requests among all the controllers shows a gradual increase in performance as the controller pool grows (Figure 5.6b). For 1 controller, it maintains RTT at approximately 4ms up to 1000pps with 2 controllers RTT of less than 4ms up to 1500pps. At 5 controllers, it maintains an RTT of 4ms up to 4500pps. The Load Aware distribution algorithm shows similar results with the same controller pool (Figure 5.6c) but performs slightly better at 5000pps. With 5 controllers, the Round Robin registers an average RTT of 93 ms while the the Load Aware Load Balancer maintained an RTT of approximately 11 ms.

With the Non-Homogeneous controller pool, the Stock OvS’s policy of sending all requests to all controllers works out well in this case as it is able to find at least one controller (the Floodlight controllers) which provides good service. Thus, it is able to with 2 or more controllers, it is able to maintain an average RTT of 1-2 ms. In a different network, with less well provisioned controllers, this may not be the case (as we saw with the Homogeneous pool). As stated before, the controller pool is as good as its best controller under the Stock OvS but it does not make the best use of resources. The Round Robin distribution Algorithm in Figure 5.7b shows a no- table increase in performance when used with the Non-Homogeneous controller pool, providing better RTTs than the Homogeneous controller pool (for example with 2 controllers is approximately 112ms between 2500pps and 4000pps while there was no connectivity over 2000pps for the Homogeneous pool). With the introduction of the Floodlight controllers to the Round Robin distribution by the switch, the service of the pings becomes a game of chance- whether the pings will be sent to a Floodlight controller and receive good service, or be sent to a Ryu controller and receive delayed service. With 2 Ryu controllers (Figure 5.6b), the Round Robin load distribution stopped receiving service after 2000pps, however with 1 Ryu and 1 Floodlight controller, some were sent to the Floodlight controller which reduced the overall average RTT of the 20 pings. The pings actually have a better chance of re- ceiving service with 2 controllers than with 3 as there is a 50% chance of being sent to the Floodlight controller vs a 33% chance with 3 controllers. This may explain why

between 3000 and 4500pps, 2 controllers provide better service (112ms-120ms) than 3 (approximately 135ms)-more pings went to the Floodlight controller. As shown in the Controller Performance tests (Section 5.2.1), the Load Aware distribution algorithm in the switch is able to exploit the disparity in performance by weighting the better performing controllers with more flow requests. The result of this here is that it provides the best response times and latencies for multiple controllers giving the minimum latency in the RTTs in each case- 2ms-6ms (Figure 5.7c). It produces optimal network performance due to its ability to intuitively detect which controller is best suited for the incoming flow request ensuring the fastest responses and fewest dropped requests.