## 4 Implementation
### Flow-Centric Visibility to Assist Networking Control
Regarding memory usage, we observed similar values for both base collection and TCP-sync collection in both user-space and kernel-space tracing, thus detailed figures are not reported. Figure 10 shows the significant differences in the amount of traced data between base collection and TCP-sync collection, in both kernel-space and user-space tracing. Notably, the lowest amount of traced data was observed for TCP-sync collection in the kernel space, indicating potential for detecting TCP-based SYN attacks with less than 1 MB of traced data over a two-minute measurement period, with an attack rate of 1 Mbps. Figure 9: CPU measurement results. #### 5.3.2 Processing Efficiency of Flow-Centric Visibility

The performance evaluation of our flow-centric visibility solution mainly focused on a detailed assessment of the visibility integration solution's efficiency. We meticulously compared the number of collected data to the clustered, identified, and mapped policy data. As the volume of traced packet data increased, we measured the processing time of the Spark-based visibility integration to assess the overall performance of our solution. For the performance evaluation, we set up a two-node cluster using two physical machines, each with 8 CPU cores and 16 GB of memory. One machine served as the master, while the other functioned as the Spark worker, executing the flow-centric visibility application. The Spark analytics engine was configured to run in a standalone cluster mode. Our experiments involved different configurations of CPU cores and memory assignments for both Spark Driver and Spark Executor processes to evaluate performance under various network packet flow counts (i.e., ranging from approximately 0.5 to 2.0 million). In Scenario 1, we configured the Spark Driver with one CPU core and 2 GB of memory. In Scenario 2, we configured Spark Driver with 2 CPU cores and 4 GB of memory. In Scenario 1, as shown in Figure 10(a), all three executor configurations display a positive linear trend, indicating that the time required (i.e., in seconds) to classify data increases proportionally with the input data size. This trend demonstrates the flow-centric visibility solution linear scalability concerning data size. Notably, the time differences between the various executor configurations are minimal, suggesting that the performance limitation probably arises from the single CPU core and 2 GB memory configuration of the Spark Driver rather than the executor configurations. Like Scenario 1, as shown in Figure 10(b), all three executor configurations in Scenario 2 display a positive linear relationship between data size and classification time. However, overall time is slightly lower across all executor configurations than in Scenario 1. This performance improvement can be attributed to the enhanced resource allocation to the Spark Driver, which enabled better handling of larger network packet flows and more efficient management of distributed computing tasks. Both graphs from our performance evaluation demonstrate scalability in terms of input data size, as indicated by the linear increase in processing time with increasing data volume. This linearity shows the flow-centric visibility solution's ability to handle larger network packet flows effectively. However, the flattening of differences between executor configurations as data size increases may indicate that we are nearing a point where additional gains from additional executor resources are limited unless coupled with equivalent increases in driver capabilities or optimizations in data handling and task distribution strategies. Figure 10: Total traced data in kernel and user spaces. In summary, our analysis indicates that increasing the number of assigned resources to the Spark analytics engine improves the efficiency of the visibility integration solution, as evidenced by the linear increase in processing times with larger network packet flow data.