# Transport-Layer Limitations for NFV Orchestration in Resource-Constrained Aerial Networks
## 4 Practical Evaluation of Transport-Layer Options
### Orchestration Traffic Performance with Background Data Traffic  
In the previous test set, we analyzed the behavior of TCP in an intermittently available SUAV environment in complete isolation from any other traffic inside the network (except OLSR traffic, which is neglectable since it is not very frequent and does not generate much traffic). Nevertheless, typical networks do not behave this way: in all NFV platforms, VNFs will generate traffic to either communicating with other VNFs in the same network or sending traffic outside the network, e.g., sending traffic to the Internet. Hence, this orchestration traffic is not isolated, forced to share the available wireless channel with data communications, which in turn can further affect its performance. With these new test sets we aimed at checking performance for orchestration traffic in a saturation environment using TCP. We performed the same tests with a slight difference: we saturated the network with background TCP traffic to simulate the presence of VNFs exchanging information using the data plane. In this respect, we appended two new traffic sources to our reference scenario: a TCP source attached to SUAV (3,1) sending traffic to SUAV to (2,4), and another one attached to SUAV (1,3) transmitting TCP traffic to (4,3). In both cases, the TCP sources use the maximum transmission rate possible, according to TCP congestion control mechanisms, to analyze the performance of the orchestration traffic under congestion conditions. The results of this experiment can be seen in Figure 5. As it can be observed in this figure, the performance of orchestration traffic clearly decays compared to the idle case: traffic spikes are more frequent and overall throughput is lower. Nevertheless, same periods where no orchestration traffic are still present in the same spots, since the SUAV substitution times did not change. However, there are even more traffic spikes than before because the aircraft only send all of its accumulated traffic (including TCP retransmissions in that case) once it has the opportunity to forward it, which will depend on the TCP connections saturating the network since they are the ones occupying most of the channel bandwidth, resulting in a more irregular throughput distribution with higher traffic bursts, negatively impacting NFV orchestration. The reason of this behavior relies on how the forwarding aircraft deal with orchestration traffic in these conditions: if the transmission buffer of a node in the routing path is full, and either the channel is completely occupied and or a link in the path breaks, it will discard incoming packets since it does not have any more space, dropping those ones that arrive to this node until it has the opportunity to forward that traffic. Hence, more packets will be dropped in the scenario, potentially losing control information useful for the NFV orchestration service. This turns UDP into an attractive solution as an alternative to TCP, whose congestion control mechanisms penalize the performance of orchestration traffic due to the intermittencies present in this medium, both in the absence and presence of background traffic. Nevertheless, the ability to produce retransmissions is still desirable in certain situations, e.g., to avoid missing important orchestration information from the VIM. In any case, we want to highlight that the decision on which information should be delivered reliably, and thus retransmitted if lost, should take place at the application layer (i.e., retransmissions should be implemented as required by the VIM and by the orchestration application services running at the compute nodes). As an example, if the network path between the VIM and a compute node is unavailable for several seconds, the retransmission of information regarding the status of a compute node resources may not be necessary, as the information concerning this status may be outdated once the network path is recovered, and a new application-level request formulated by the VIM may be preferable to get up-to-date status information.