## 6 Performance Evaluation
### Simulation Results  
The first set of results, shown in Figure 5, report the service provisioning time for the compared schemes under different workload settings in terms of size of the content to be processed (\(\sigma\)) and arrival rate of service requests (\(\lambda\)), when fixing the Zipf parameter \(\alpha\) equal to 0.8. For the cloud solution, the metric is not affected by the parameter \(\lambda\): the cloud can sustain high processing loads compared to the edge nodes. The processing time contribution is negligible compared to the latency incurred in retrieving the input content. In fact, the larger the content size, the higher the service provisioning time. The LLE strategy, on the contrary, is highly affected by parameter \(\lambda\). The considered metric highly increases with \(\lambda\). The LLE performance is superior to the one experienced by the cloud solution for small arrival rates. This is especially true for large content size settings. As \(\lambda\) increases, instead, the service provisioning time gets higher than the one provided by the cloud and approaches 10 s.  
The CE strategy behaves quite poorly because nodes get rapidly loaded for larger values of \(\lambda\). The metric does not change significantly as the content size increases. This is because the waiting time before the processing, which is inevitably experienced at the nodes close to the producers, is much more significant than the time required to retrieve the input content. Our proposal outperforms the compared schemes under all the considered settings by scaling better with the size of the content and the arrival rate of service requests. However, due to the limited available processing resources at the edge nodes, its performance approaches the one experienced in the case of the remote cloud for high \(\lambda\) settings. \begin{table}
\begin{tabular}{l l} \hline \hline
**Parameter** & **Value** \\ \hline Number of services & 1000 \\ Zipf’s parameter & 0.4, 0.8 \\ Request arrival rate (\(\lambda\)) & Varying (10–80 requests/s) \\ CPU requests of services & Uniformly distributed in [25; 750] Mcycles \\ Edge link latency & [5; 10] ms \\ RTT to the cloud & 50 ms, 100 ms, 150 ms \\ CPU node capabilities & [250–1500] MHz \\ Content size (\(\sigma\)) & [500, 1000, 2000] 1024 large packets \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Main simulation settings. The better performance of the proposal has to be ascribed to the possibility to select as candidate executors also nodes that are off-path, i.e., in the path towards the cloud (and not only in the one towards the data producers) and the remote cloud itself, as the ultimate solution. This is confirmed by results in Figure 6. Notably, only a small percentage of services are offloaded to the cloud and only when the parameter \(\lambda\) is large. The larger the content size, the lower the offloading-to-the-cloud percentage. This is because the latency contribution due to content retrieval by IoT producers gets more significant for the cloud. Figure 5: Service provisioning time when varying the service request arrival rate (\(\lambda\)) for different content size settings (\(\sigma\)), \(\alpha=0.8\). Figure 6: Offloading-to-the-cloud percentage for the NDN-fog solution when varying the service request arrival rate (\(\lambda\)) for different content size settings (\(\sigma\)), \(\alpha=0.8\). The supremacy of NDN-fog compared to the benchmark schemes is paid in terms of a larger amount of traffic generated in the domain, as shown in Table 3. For small content size settings, the intra-edge exchanged traffic for NDN-fog approaches values experienced by the cloud solution. As the content size increases, the intra-edge exchanged traffic in NDN-fog gets smaller compared to the cloud, although it is still higher than the CE solution, performing the execution as close as possible to the data producers.