## 5 Experiments
### Experiment 1: Two Extreme Cases  
The _purpose_ of this experiment is to measure the _time elapsed_ and _resources consumption_, corresponding to the first and third metrics of Section 3.3 following the two naive approaches presented in Section 4. Keep in mind that both these cases should not be treated as viable options, as they require either extreme time or resources. Regardless, they provide an upper/lower bound for alternative strategies. \begin{table}
\begin{tabular}{c c c c c c} \hline \hline  & \multicolumn{3}{c}{**Time (s)**} & \\ \hline
**Replicas (r)/Connections (c) Num.** & **10** & **20** & **30** & **40** & **50** \\ \hline \(S(r)\) & 5.13 & 7.77 & 10.36 & 13.75 & 18.04 \\ \(F(c,s)\) & 0.002 & 0.005 & 0.008 & 0.011 & 0.015 \\ \(R(c,s)\) & 0.006 & 0.015 & 0.021 & 0.029 & 0.033 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Average times for all the actions performed per epoch for various replica numbers and connection pools. In the _serial approach_, we spawn a single replica server, sequentially migrating one connection at a time. Each connection operates in isolation in the replica server. Since it is the only connection running in that node, if it is malicious, it causes an observable effect. In this case, there is certainty regarding the status of the connection (malicious, or benign) and then it can be isolated immediately. Because all operations are performed sequentially, requiring many evaluations (as many as the number of connections), this approach requires the maximum time. However, concurrently, only one replica server is needed, and for this reason, it consumes the minimum amount of resources. The _parallel approach_ operates as follows. We spawn a number of replica servers equal to the number of connections. Then, simultaneously, we migrate each connection to its own replica server. Again, in parallel, we check the health status of each replica. While this approach requires the maximum number of replicas, it takes the minimum amount of time to reach a complete solution. Both these approaches are illustrated in Figure 2.  
Both these approaches require the same time and resources, irrespective of the pollution factor. This is because both adopt an exhaustive, brute-force method, examining every single connection. In the parallel approach, the total time required does not exceed one minute for identifying the status of all connections. However, as expected, the serial approach requires much more time to converge to a full solution. More specifically, the simulations indicate that the total time increases by \(\approx\)80-90 min for every 1K additional connections. For 10K connections, it takes roughly 14 h or 835 min for the completion of the scheme. The serial approach requires precisely a single replica to evaluate each of the connections, while in the parallel case, each of the connections is evaluated in a separate replica server spawned for the same purpose. In other words, the number of replica servers that are required in the parallel approach increases linearly according to the number of connections. The results are illustrated in Figure 3 and outlined in Table 2.  
**Takeaways**: The time and replicas needed to reach a complete solution scale linearly based on the total number of connections. However, for a large number of initial connections, the described approaches become prohibitively expensive either in terms of time (serial approach) or resource (parallel approach) requirements. More specifically, the serial approach requires more than 835 min to reach a full solution when 10K connections are considered. Similarly, the parallel approach necessitates the spawning of 10K replicas assuming the same parameters. Figure 2: Two extreme approaches as partition strategies. The use of a single replica server involves significant time to converge to a full solution; however, it has the minimum requirements in terms of replica servers spawned (**left**).