# Megalos: A Scalable Architecture for the Virtualization of Large Network Scenarios +
## 7 Evaluating the Scalability
### Startup Scalability  
We performed three different types of experiments. In the first experiment, we focus on measuring Megalos performance with respect to the amount of time needed to deploy network scenarios compared with Kathara. In particular we used Kathara version 3.10 both with the default multi-thread execution, and  
Figure 4: Results of the latency test. The green and the blue curves show the RTT measured in the scenario composed by a chain of \(n\) routers. The green curve corresponds to the Megalos implementation while the blue curve corresponds to the single-host one. The red curve represents the portion of RTT that is either intrinsic of the inter-container communication or depends on the physical latency of the cluster. forcing a single-thread execution. In contrast, we measured the startup times of Megalos both with one worker and 24 workers. We ran this test over several network scenarios, increasing the number of VDs. The results, shown in Figure 5, highlight the ability of Kubernetes of schedule VDs in a distributed way. It is apparent that Kubernetes takes advantage of the number of worker nodes (horizontal scalability) more efficiently than what it gains by increasing the number of threads (vertical scalability). Conversely, Kathara, being single-host, is favored only by increasing the number of threads. From Figure 5 it appears that single-worker Megalos has startup times equivalent to those of single threaded Kathara and that multi-worker Megalos has startup time equivalent to those of multi-threaded Kathara. In the second experiment, focusing on the application of Megalos to a real-life networks, we considered the startup time of Fat-Tree networks, which are commonly used in data-centers. Figure 6 shows the number of VDs, the number of interfaces, and the startup time in minutes (average of five measures) depending on the fundamental parameters \(K\) (north/south switch ports) and \(R\) (redundancy factor, a divisor of \(K\)) of the Fat-Tree. Each VD of the Fat-Tree has \(2K\) interfaces and the number of VDs is given by the formula \(\frac{5K^{2}}{R}\)[55]. In Figure 6, the color intensity of the blue heatmap in the background is proportional to such a number. In particular, we have networks with number of VDs ranging from 10, for \((K=2,R=2)\), to 1280, for \((K=16,R=1)\). White boxes correspond to experiments performed on a local virtual cluster composed of 22 worker nodes, each with 2-core vCPUs and 8 GB of vRAM. Black boxes correspond to experiments performed on an Azure cluster composed of 160 worker nodes, each with 4-core vCPUs and 8 GB of vRAM. As expected, the startup times increase with the number of VDs. Notice that the startup times also strongly depend on the number of interfaces. For example, the networks generated for \((K=16,R=16)\) and \((K=8,R=4)\) have the same size in term of VDs, but a different number of interfaces, and this strongly impacts the resulting startup time. As it was the case for the previous measures, it is apparent that Megalos takes advantage from the size of the available cluster. The startup times are much lower for the Azure experiments (black boxes of Figure 6) with respect to the local cluster (white boxes). Overall the startup times are, in our opinion, acceptable for practical use. The largest network (1280 VDs and 33,280 interfaces) was launched in about half an hour. Figure 5: Startup times (green curve) of several network scenarios with a growing number of VDs hosted in 24 Kubernetes worker nodes. For comparison we also show startup times for the cases when all VDs are hosted in a single Kubernetes worker node (blue curve); when all VDs run within Kathara single-threaded (red curve); and when all VDs run within Kathara multi-threaded (orange curve). Motivated by the result of the second experiment, in the third experiment we measured the impact of the number of virtual interfaces on the startup time. In particular, we launched a single VD with an increasing number \(n\) of virtual interfaces, with \(n\) ranging from 1 to 150.