# Transport-Layer Limitations for NFV Orchestration in Resource-Constrained Aerial Networks
## 4 Practical Evaluation of Transport-Layer Options
### Additional Considerations and Transport-Layer Approaches  
After performing the tests and analyzing their results, we still need to consider some additional points that involve these connections and/or the platform itself. First of all, even though control information should have higher priority against traffic data, this should not always be the case: in NFV orchestration, asking about resource state is not the only type of orchestration traffic an NFVO generates: it can produce NFV instantiation deployments, scaling instructions... that will add more traffic to the network, even saturating it at some point (e.g., instantiating VNFs for the first time in a node). Therefore, a smart VIM should be able to balance the competition between orchestration and data traffic, which has to be taken into account when developing a solution based on UDP, since  
Figure 6: (**a**) Received throughput on SUAV (4,4) using UDP as transport-layer protocol without saturation conditions. (**b**) Received throughput on SUAV (4,4) using UDP as transport-layer protocol under saturation conditions. sending a large amount of orchestration traffic through the network could induce packet losses and impact the performance not only of data-plane traffic, but also of orchestration traffic exchanged by other SUAV nodes, harming the performance of the network services deployed over the aerial network and of the orchestration process. Precisely, this is one of the main disadvantages of using UDP as an alternative to TCP for orchestration traffic: NFV-related control packets could be lost in the delivery process. Since UDP does not have any kind of retransmission mechanism, an alternative way to ensure its reliable delivery is necessary in this environment. In this respect, reliable data transfer could be guaranteed at the application level, either directly by the MANO system or by using a middleware solution. This would allow keeping all advantages from UDP while retaining reliable delivery. Moreover, managing retransmissions of data to ensure reliable transference at application level might be the best solution, since TCP may retransmit outdated information while there is no path to the aircraft/GCS: with an application layer oriented solution however, the retransmitted information could be managed better to ensure providing the most recent information as possible. One example of these solutions could be using the Delay Tolerant Networking (DTN) concept, a promising solution which can spread the control information along the network without being disrupted by replacements, as the information is only forwarded hop-to-hop once a link is available [44]. However, this is a double-edge sword: this information should not remain in the network more time than necessary, since it will be outdated once it reaches its destination if the information remained in transit too much time. Therefore, a solution with this paradigm should consider network latency to avoid spreading outdated information to the NFV nodes. As we have already mentioned, in the simulations we used the OLSR routing protocol, because it is a well-known and recognized standard, with an existing implementation in NS3, and our prior work indicates that it provides appropriate performance metrics in scenarios as in the one considered in this section. However, it is important to point out that choosing other protocols could impact traffic performance, since additional mechanisms and variables have to be taken into account as well (e.g., route discovery mechanisms, timers, header size, etc.). In a real-life scenario with resource-constrained devices, it would be essential to select a suitable routing protocol that ensures an appropriate performance in the dissemination of management and orchestration information. In this respect, there are several alternatives that could be taken into account to support network routing, such as AODV [34], DSR [33], and AERO [45].