## 6 Verification and Results
### Episode 1: Packet Forwarding and Provisioning (req: i, iii, iv, vi)
#### 6.1.2 Throughput  
According to the requirement of adoption (req: vi), we argue that the architecture fulfils this requirement by using fully virtualised overlay networks. The new NSH header only needs to be implemented in virtualised environments and therefore it is also easily deployed in fully isolated, autonomous and customer-specific environments. However, other important factors for adopting the architecture are scalability and throughput performance. The TCP throughput is a product of bit rate, packet-size and latency. Hence, the latency factor for throughput performance is highly dependent on the number of NSH forwarders, their latency in processing packets and the latency between them. Hence, we measured the throughput by varying the number of SF and EF hops (Figure 9). We tested the throughput from the client to the server by using an Iperf TCP bandwidth test with window-size 512.  
The results (Figure 9) show a decreasing throughput when the number of SF hops increases. The main reason behind this result is the increased latency that the virtual machines introduce. We measured that a VM with a P4 enabled switch in average used 6 ms to process a packet. The virtualisation software we used for P4 is based on CPU processing without any network accelerator  
\begin{table}
\begin{tabular}{l l l l l} \hline \hline
**Episode** & **Test Name** & **Packet Rate** & **Packets Lost** & **Outage Time** \\ \hline
1.a & **Full provisioning** & 64 pps & 13,184 & 206.0 s \\
1.a-1 & -SF instantiation & 64 pps & 3049 & 47.6 s \\
1.a-2 & -EF instantiation & 64 pps & 10,176 & 159.0 s \\
1.a-3 & -Auth and encr. setup & 64 pps & 81 & 1.2 s \\
1.a-4 & -Distribution of flow rules & 64 pps & 0 & 0.0 s \\
1.b & **Soft provisioning** & 64 pps & 154 & 1.2 s \\
1.b-1 & -Auth and encr. setup & 64 pps & 81 & 1.2 s \\
1.b-2 & -Distribution of flow rules & 64 pps & 0 & 0.0 s \\
1.c & **Periodic keychange (every 5 s)** & 64 pps & 7 & 0.1 s \\ \hline
2.a & **Failover with protection** & 64 pps & 326 & 5.0 s \\
2.a-1 & -Detection time & & & 5.0 s \\
2.a-2 & -Distribution of flow rules & 64 pps & 0 & 0.0 s \\
2.b & **Failover without protection** & 64 pps & 13,504 & 211.0 s \\
2.b-1 & -Detection time & & & 5.0 s \\
2.b-2 & -Full provisioning & 64 pps & 13,184 & 206.0 s \\ \hline \hline \end{tabular}
\end{table}
Table 1: Provisioning times.  
driver. This lack of suitable software drivers for P4 explains this latency. However, it is expected that new generations of OVS, IPAC and other P4 runtime environments will decrease the packet processing latency in future releases of the P4 runtime frameworks.  
However, the most important factor with respect to NFV adoptability (req: vi) is how much degradation in throughput the encrypted links introduce. Hence, we measured the difference between EF and SF hops, by creating multiple SFCs with and without encrypted Virtual Links. The graphs (Figure 9) show that there is no significant difference in the throughput between an SFC with EFs only and an SFC with SFs only. This confirms that it is the P4 switch that introduces the latency and that the performance degradation is due to the P4 hypervisor or the effectiveness of the P4 program.