# Transport-Layer Limitations for NFV Orchestration in Resource-Constrained Aerial Networks
## 4 Practical Evaluation of Transport-Layer Options  
Previously, we have described the potential challenges and hurdles in NFV orchestration when dealing with intermittently available SUAV platforms. In this section, we analyze a subset of these problems from a practical perspective, performing different tests to gain a deeper understanding of their impact. In particular, we break down the consequences of using TCP as the default transport-layer protocol to support the exchange of orchestration information over SUAV networks, since some of its mechanisms could prove to be problematic in these scenarios. As mentioned in the previous section, commercial VIMs mostly use HTTP to exchange orchestration information with the compute nodes under their control. Consequently, these communications are typically established using TCP. Although this can be a good solution to support management and orchestration communications in traditional scenarios such as datacenters, where fixed network technologies at Gb/s speeds may be available, SUAV platforms behavior turns some of the principal characteristics of TCP into mechanisms that may harm the performance of orchestration traffic, instead of helping its correct delivery. One example of this is related with the congestion control mechanism of TCP in FANET environments. Typically, the operation of VIMs requires low bit-rate traffic flows to manage and monitor the available NFVI resources and the VNFs at the SUAVs. These flows should appropriately be delivered given the bandwidth that may typically be present in wireless ad-hoc networks [5]. Theoretically, TCP should not decrease its traffic rate if the network has no congestion, since that will be ineffective in those cases. However, the presence of constant link breakdowns, due to both wireless link issues and SUAV replacements, can produce excessive TCP retransmissions or, in worse cases, sever the network path between the GCS and a SUAV completely, if an intermediate wireless link that has failed does not recover in a reasonable period of time. Moreover, given its importance to effectively coordinate the available NFV resources, we may want to prioritize the delivery of management and orchestration information against other kinds of traffic, as long as it does not monopolize the available bandwidth for data communications. This last point is fundamental, since achieving a timely dissemination of orchestration information is essential to efficiently manage the NFV resources present in the aircraft. Having analyzed from a theoretical perspective how using TCP connections may affect management and orchestration operations in SUAV environments, we address a more detailed evaluation of this impact using a simulation platform. In particular, we use the well-known Network Simulator 3 (NS3), since it is flexible enough to simulate a target scenario with multiple SUAVs, while at the same time enables fundamental features such as SUAV replacements, the establishment of simultaneous TCP and UDP communications, and the provision of detailed traffic captures for their subsequent analysis [39]. Figure 2 shows the considered reference scenario at the evaluation. We want to highlight that in a prior work [5], we developed a functional prototype of an NFV system capable of deploying virtual functions and services over resource-constrained SUAV networks. The results of that research work, provided the quantitative proofs for the assumptions made in this practical evaluation. The reference scenario comprises 16 SUAVs, interconnected in a 4 \(\times\) 4 grid topology, and a GCS with two points of access to the aerial network conformed by the SUAVs. The chosen topology enables study of the performance of management and orchestration operations in a favorable environment, where multiple network paths exist between the GCS and each SUAV for the exchange of control information (i.e., there is no single point of failure).