## 4 Simulation and Experimental Results
### DDoS Simulation Attacks  
To extensively simulate the network, we carried out up to five relevant DDoS simulations, first in a single-attack scenario and then in a scenario where multiple DDoS attacks occurred at the same time. To run the simulations, we provided two Ubuntu virtual machines--one for the controller and the other for the simulating network--on a machine with an Intel Core i7-4600U processor with 8 GB of RAM. Mininet was used as a support tool for simulating the network and creating the network topology and the hosts. Figure 3 shows the architecture topology that we implemented in Mininet for the preliminary tests; no attacks occurred here. The figure provides an intuition of the network set-up that is required to operate such an edge scenario. For the video streaming task, we used the well-known _FFmpeg_ software, which is a Linux-based standard tool for video and audio streaming. The following results are intended to be a basilar comparison between networks without attacks and networks facing attacks. In particular, we calculated the performance of the fully operative network without attacks. We recorded an average throughput of around 4 Mbit/s (the upper bound limit we chose in Mininet) and an average RTT of around 0.2 ms. Finally, in the following experiments, we observed the behavior of the network in an 80-s time window. In each observed experiment, DoS attacks started after around 30 s of the observed window. To see how DoS attacks affect possible services in the network, two scripts were used to simulate a streaming service via the _FFmpeg_ command. In particular, as shown in Figure 3, host H6 was used as a server and host H1 as a client that was sending an mp4 video to the server continuously, just as in video streaming, to simulate object recognition tasks, for instance. In all simulations, the _hping3_ tool was used to simulate DoS attacks to the SDN controller, and the options used are described in Table 2.  
Furthermore, enabling the random source address is a very important option for the attack. In the SDN paradigm, when a switch receives a packet, it checks if there is a flow \begin{table}
\begin{tabular}{l l} \hline \hline
**Parameter** & **Description** \\ \hline -flood & Flooding mode sends packets as fast as possible without taking care to show incoming replies \\ \hline -rand-source & This option enables bring to send packets with random source addresses \\ \hline -lP ADDRESS\(>\) & IP destination target of the attack \\ \hline \hline \end{tabular}
\end{table} 
Table 2: HPING3 options. Figure 3: The SDN-enabled architecture used for simulations. Figure 2: [PERSON] internal implementation architecture. rule for that packet. If that rule exists, the switch can forward the packet to the destination. Otherwise, the packet is stored in a buffer, and the packet is forwarded to the controller. The use of a random source IP for packets allowed us to generate a large number of packets missing the switches and, consequently, to forward packets to the controller. Indeed, the controller will be flooded with many packets to process and write flow tables back to the switches. Nonetheless, the capacity of a switch's buffer is limited, and some benign rules may be overwritten, thereby rendering the switches completely offline. As a result, many packets are being dropped, causing a bottleneck to the controller, which results in low throughput and a longer delay in the whole network. A large number of simulations was completed. In particular, five different simulations are presented in this paper in increasing order of relevance. The global goal was to see the network's response to DDoS attacks and hence the idea to simulate several possible scenarios. In particular, we differentiated the experiments by changing the attackers and target hosts in order to figure out how different attack positions affected the service.