# Application-Aware Network Traffic Management in MEC-Integrated Industrial Environments
## 6 Prototype Description and Evaluation
### Experiments and Performance Results
As Figure 4(a) illustrates, the CPU usage grew to about 2000 milli-CPU at 10K MPS and above 1500 milli-CPU at 8K MPS. Given that Figure 4(a) depicts the experiments while CPU limited to 500 milli-CPU, it means Kubernetes scaled up to four replicas (i.e., the maximum allowed) to cope with such message rates. The comparison between Figure 4(a),b points out the system responsiveness with different CPU limits. In Figure 4(a), the lines about incoming rates of 6K, 8K, and 10K MPS still grow at the end of the time window (200 s), while all the lines reach a steady-state phase in Figure 4(b). This is because replicas available at a given time could take extra resources (over the CPU request) while horizontal scaling occurred. As Figure 4(c) shows, replicas that can benefit from a higher CPU limit outperform those that cannot do it (500 milliCPU vs. 1000 milliCPU). For instance, the percentage of processed packets was 57.6% (500 milliCPU limit) against 92% (1000 milliCPU) at 10K MPS. Lastly, Figure 4(d) reflects this point in terms of average CPU usage. As the reported results clearly show, horizontal autoscaling combined with a flexible resource cap was effective for performing SE, even while dealing with the worst-case scenario (i.e., 10K MPS). When dealing with HE, however, the performance was considerably different. In this regard, Figure 5(a) (note the logarithmic scale on the y-axis) shows the CPU usage while performing HE, HA, and HD on an incoming rate of 2K MPS. In this case, there were no resource requests or limits in place. This means eINP modules could take as many resources as they can from their host. Over the observed time window, the average CPU usage while performing HE (i.e., 890 milliCPU) was roughly 10 and 40 times higher than HA (i.e., 91 milliCPU) and HD (i.e., 23 milliCPU), respectively. In addition, Figure 5(b) shows the average per-message processing time, which is the time needed by the module to send a message after its reception. Specifically, the average per-message processing time was 10 times faster during HA (i.e., 35 ms) than HE (i.e., 349 ms). It is worth noting that while performing HA, only one out of 10 messages is homomorphically processed, whereas the processing time is negligible for the others. Lastly, the average per-message processing time while performing HD (i.e., 100 ms) was slower than HA but more than three times faster than HE. Based on the results we collected, we can state that in MEC-integrated industrial environments, eINP modules may be deployed both on- and off-premises. However, steering sensitive data on off-premises resources (i.e., MEC nodes) raises confidentiality issues. To fill that gap, we proposed providing the network with data encryption capabilities (i.e., SE and HE) through edge computing to enforce confidentiality even for those traffic flows originally sent out in cleartext. Although SE guarantees much better performance than  
Figure 6: eINP modules performing homomorphic encryption, averaging, and decryption. HE, SE requires that keys are shared between parties (i.e., industrial environment and MEC nodes) and that sensitive data must be decrypted before processing. This is not always a viable option, especially when confidentiality must be guaranteed all along the way. In this regard, HE could solve the issue because homomorphically encrypted data are left encrypted while processed, but it comes with a price. Our results suggest that HE is only practical if (i) a relatively high amount of edge computing resources are available on-premises, or (ii) a low MPS rate characterizes the target traffic flow (note the measured average per-message processing time of 349 ms while performing HE). Accordingly, the key takeaway is that there is no one-size-fits-all option, but the tradeoff between performance and confidentiality must be carefully evaluated depending on application-specific requirements and the characteristics of the targeted deployment environment.