# Application-Aware Network Traffic Management in MEC-Integrated Industrial Environments
## 6 Prototype Description and Evaluation
### Experiments and Performance Results  
The experiments varied along three dimensions. The first dimension was the rate at which the industrial machine sent out messages. In this regard, we set increasing rates from 2K to 10K Messages Per Second (MPS) in steps of 2K MPS. Each message was a UDP packet with a fixed payload size of 212 bytes. The second dimension was the CPU usage to which the containerized eINP module was limited. Note that Kubernetes uses milli-CPU as the base unit for expressing amounts of CPU and allows specifying both CPU requests and limits [43]. Specifically, a CPU request states the minimum amount of CPU a container needs to run, and a CPU limit indicates the maximum amount of CPU a container can take while running. For all the experiments, we fixed the CPU request to 500 milli-CPU and tested the target eINP module with CPU limits of 500 milli-CPU and 1000 milli-CPU. When a container sets its CPU limit higher than its CPU request, it may benefit as follows. If a burst of messages causes a peak of computational demand, the container may successfully handle the incoming traffic by taking resources beyond its request. Otherwise, the container would run out of resources. Secondly, the horizontal autoscaler decides whether to scale replicas based on the ratio between the current CPU usage and the average of the given target values across running replicas, with a tolerance of 0.1 by default (please see [44] for more details). Given that a higher CPU limit allows a potentially higher CPU usage, the horizontal scaling is faster when peaks of computational demand occur. For all the experiments, the average target utilization was 80%, the minimum number of replicas was one, and the maximum number of replicas was four. The third dimension was the eINP module under testing. * Duplication & Aggregation (D&A): This module de/serialized incoming messages and detected mission-critical information with a probability of 5%. Such messages were duplicated and sent to the technician's laptop in a timely manner. Then, the module performed aggregation, reducing outgoing traffic by 90%. * Symmetric Encryption (SE): This module de/serialized incoming messages, encrypted their contents with a Python implementation [45] of the AES algorithm [46], and forwarded them to the MES. * Homomorphic Encryption (HE): This module de/serialized incoming messages, encrypted their contents with a Python implementation [47] of the Paillier algorithm [48], and forwarded them to the MEC node. * Homomorphic Aggregation (HA): This module de/serialized incoming messages, queued messages on a flow basis, computed the average value of a target homomorphically encrypted field as soon as a queue grew up to ten elements, and sent out them to the MES. * Homomorphic Decryption (HD): This module de/serialized incoming messages, decrypted their contents, and forwarded them to the MES. To statistically support our findings, each module has been tested by repeating the experiments five times, and each run of an experiment captured a time window of 200 s (in Figure 5, each data point is the average value of five runs). Note that the following performance results are scenario-agnostic, thus providing the readers with insights about the elNP modules under testing, regardless of the employed industrial network topology. While performing D&A, the average target utilization we configured (80%, meaning 400 milli-CPU) is not even triggered except for the worst-case scenario (10K MPS). It is worth mentioning that D&A is very efficient. In fact, aggregation dramatically decreases outgoing  
Figure 5: elNP module performing symmetric encryption with different milli-CPU limits. messages, cutting down JSON serialization and forwarding costs. The key takeaway is that the eINP module correctly processed almost every packet at any incoming rate. In contrast to D&A, SE is a CPU-intensive task. This makes horizontal autoscaling critical, even at relatively low message rates.