# Transport-Layer Limitations for NFV Orchestration in Resource-Constrained Aerial Networks
## 4 Practical Evaluation of Transport-Layer Options
### Orchestration Traffic Performance Using TCP  
For this first test, we aim at checking orchestration traffic behavior when using TCP under constant link breakdowns due to battery depletions. As we have previously mentioned, the simulation will use two CBR sources with 5 kb/s to represent the GCS-to-SUAV communications and 7 kb/s for the UAV-to-GCS communication. Under normal conditions, where SUAVs do not require a battery, i.e., they are considered fixed nodes (left on the ground connected to the electrical network, for example) these rates are stable thought all SUAV communications except, for minor losses due to medium itself (neglectable loses). However, once sporadic link breakdowns become part of the equation, throughput is negatively affected when TCP is the transport-layer protocol, due to its congestion avoidance mechanism. Even though this functionality does prevent the source from sending more traffic to the network, it will affect the connection health since the links will never be congested with these type of orchestration traffic because the amount of traffic generated from these sources is very small compared to the available bandwidth. However, several temporary link breakdowns will affect those links because the sources will generate excessive retransmissions (which are unnecessary in this context since the problem is temporal). Moreover, using OLSR as our default routing protocol will require several route recalculations every time a node has to be replaced. This will impact all communications being forwarded on that node, and the relatively long update times (every 10 s an update message is broadcasted to its neighbors) might leave some aerial nodes without a network path with the GGS and, in consequence, will prevent the aircraft from receiving any control information for a certain amount of time, and the GCS of retrieving information regarding the status of those nodes. This is not a problem originated at the transport level, and it would still be present even if we used an alternative protocol to substitute TCP, e.g., UDP, because we will still need to wait until the routing protocol converges again to find an available route. However, this route convergence time will trigger the congestion avoidance mechanisms; because TCP was created without wireless technologies in mind, all link breakdowns will be interpreted as congestion failures regardless of its true origin, since those other types of failures such as host/link teardown are much less present in completely wired networks. Therefore, TCP will start to retransmit segments using its backoff timer by scheduling subsequent retransmissions to ensure that all information is sent to the other end while leaving some space for the network to recover from the (non-existent) congestion issue. This behavior could turn into a problem in FANET environments for several reasons: while the network is still recovering when a SUAV is being replaced, packets will use outdated routes to reach its destinations, adding unnecessary retransmissions that will slightly increase the overall traffic inside the network; most importantly, if a node cannot find a route before the backoff timers expire, either because of a network related affair or because the routing protocol was not fast enough to find a route, then the TCP connection will be completely closed by the sending party, potentially leaving a SUAV without any control information until it is replaced once again, i.e., when it opens a new connection with the GCS. \begin{table}
\begin{tabular}{c c} \hline \hline
**Simulation Parameters** & **Values** \\ \hline Number of Nodes & 15 \\ WiFi Range & 70 m \\ Simulation Time & 14,430 s \\ Modulation Scheme & OFDM at 6 Mbps \\ \hline \hline \end{tabular}
\end{table} 
Table 2: This is a table caption. Tables should be placed in the main text near to the first time they are cited.