# Improving Energy Efficiency on SDN Control-Plane Using Multi-Core Controllers
## 4 Simulations and Results
### Evaluation for Maximum Latency Threshold (ICMP)  
The second scenario used the same hardware but with latency-aware traffic to simulate a full network with randomly small packets flowing. Each of the 30 hosts sends many (100) ICMP ping requests to every other host on the network, using the pingFull function from Mininet. The simulated hosts were attached to two vswitches with 15 hosts on each switch. The controller was kept the same software and hardware configuration as the first scenario.  
This scenario aims to reproduce the load pattern created by request-response network applications such as HTTP or database access. Each host sends a request and waits for a response of every other host on the network. The packets are received and response is sent in an arbitrary time, which simulates requests from applications services on the network.  
Internally, the Mininet software uses the native ping utility. Mininet pingFull function was edited to set the number of ICMP packets to send and allow ping flood mode, sending as many packets per second as possible. Our experiments were repeated 100 times for every combination of pair of hosts and controller configuration (frequency, number of cores), increasing the confidence of the results presented here.  
Figure 12 shows the energy (Joule) consumed during the latency test for 30 hosts and 2 vswitches with a max average latency of 6 ms. In addition, the total energy used during the test is shown in Figure 13. Figures 14 and 15 show the same tests in a more stringent SLA where max average latency is 5 ms.  
It is important to notice the different nature of the traffic between the latency and throughput tests. While Figures 8-10 show an almost constant energy consumption, with few dips caused by the I/O delays, Figures 12 and 14 show random intervals in which ICMP packets arrive. These two scenarios cover common stress situations on the network, namely the constant high throughput and the random time arrival of many packets. The real-world traffic will be located between the two presented scenarios: sometimes as bursts of traffic and sometimes as various smalls packets.  
Figure 12: Energy consumed during the last second that proceeds the measurement for different number of cores during network average latency test with 6 ms limit.  
Geogle has recently published an overview of its SDN control-plane called Orion [39], deployed globally in Google's data center called Jupiter. Each Orion instance runs on dedicated regular server-class platforms, where each controller uses up to 23 cores and 24 GB of memory.  
CISCO's SDN solution, as described in [40], uses the Application Policy Infrastructure Controller (APIC) as the controller. This appliance is a centralized cluster with a minimum of three controllers. Although the apic is an appliance and may also be virtualized on a CISCO-provided cloud or other cloud providers, such as Amazon and Azure, the hardware used is just the same as Google's, a regular server-class platform. The apic appliance  
Figure 14: Energy consumed during the last second that proceeds the measurement for different number of cores during network average latency test with 5 ms limit.  
Figure 13: Accumulated energy consumption for different number of cores during network average latency test with 6 ms limit.  
has two configurations L3 and M3, which use two Xeon processors of 1.7 and 2.1 GHz, respectively.  
These commercial products use the same platforms as used in our experiment but on a much larger global scale, which indicates that our finds may also apply to those larger network instances.