# Virtual Network Function Embedding under Nodal Outage Using Deep Q-Learning
## 7 Simulation Results
### Runtime  
This section will describe the performance of the model in terms of Runtime (computation time). Figures 21-24 illustrate the performance of Netrail topology and Figures 25-28 for BtEurope topology, under specified conditions. In general, it is evident from the figures that, to solve the VNF-FGE problem, BtEurope needs more significant computation time than Netrail. For example, BtEurope took \(\sim\)6\(\times\) more computation time than Netrail to embed VNF-FGs for 12 Core CPUs with 16 VNF per Core and 7 VNF per Service (see Figures 24 and 28). This increase in computation time is due to the extensiveness of the BtEurope topology.  
Figure 19: SAR: BtEurope topology with nodal outage—8 core CPU.  
Figure 20: SAR: BtEurope topology with nodal outage—12 core CPU.  
We also evaluated the consequence of the model's performance, during the expansion of core and nodal capacity. From the results, we can articulate that the computation time also increases with the increase in the core capacity per substrate node. For instance, considering the performance of 2 VNF per service case for 4 Core CPU with 2 VNF per core and 8 VNF per core (see Figure 22), we found that higher core capacity (i.e., 8 VNF per core) took an additional 2.5\(\times\) computation time for the placements; this summary is for Netrail topology without any outage. This similar effect is observed in BtEurope topology with an increase of 6\(\times\) computation time due to higher core capacity (7 VNFs per Service, 2 core CPU, 16 VNF per Core compared with 4 VNF per Core) (see Figure 25). This similar variation can be seen among the increase in nodal capacity.  
Figure 21: Runtime: Netrail topology with nodal outage—2 core CPU.  
Figure 22: Runtime: Netrail topology with nodal outage—4 core CPU.  
Likewise, a similar effect can be witnessed, with the increase in the VNFs per VNF-FG, the VL connection's complexity also escalates. Thus, it takes a more prolonged time to find an optimal link placement solution, by satisfying the upper bound on latency. However, we observe that there is an abrupt drop in the Runtimes as a general trend in all the runtime-related plots. As mentioned in the SAR section, this is because the smaller topologies are incapable of satisfying the constraint in Equation (2), causing rejection of all arriving VNF-FGs.  
We also observed that the model requires less time to find the optimum solution in terms of the nodal outage than without outage topology. This is solely due to the topology's connectivity decrease with the increase in the nodal outage percentage. Consider a 2-Core CPU case with 16 VNF per Core and 10 VNF per Services. In BtEurope topology without any outage, the model successfully embeds 25 more VNF-FGs than for 50% of nodal outage topology, but at the cost of an additional 1300 s runtime (see Figure 25).  
Figure 23: Runtime: Netrail topology with nodal uutage—8 core CPU.  
Figure 24: Runtime: Netrail topology with nodal outage—12 core CPU.  
Figure 27: Runtime: BtEurope topology with nodal outage—8 core CPU.  
Figure 25: Runtime: BtEurope topology with nodal outage—2 core CPU.  
Figure 26: Runtime: BtEurope topology with nodal outage—4 core CPU.  
On the comparison between the topologies, the Netrail Runtime is generally smaller than BtEurope. This is because, for a small topology, the action space is within the range of 7, which causes a faster search to obtain the optimal solution. However, for a dense network like BtEurope, where the action space is much larger; this generates a more massive investigation to find the optimal solution.