2.1.1 Illustration of ATN/OSI applications

The ATN applications are categorised into two types including air-to-ground [10] and ground-to-board applications [11, 12]. The air-to-ground applications include the context management (CM), which establishes a link between two entities, CPDLC, automatic dependent surveillance (ADS), flight information service (FIS), and so on. For ground-to-ground category, there are ATS interfacility data communication (AIDC) and ATS message handling service (AMHS).

COTP4 protocol is the basic transport protocol for ATN/OSI. It operates over a connectionless network protocol (CLNP). The link and physical layer protocols are defined according to the physical links concerned [13].

2.1.2 COTP4 transport protocol

The COTP4 main purpose is to provide a reliable transport service by detecting the presence of bottlenecks or congestion likely to limit overall performance, and by managing time constraints during packet transmission. COTP4, designed to be deployed at the transport layer, can operate with connection-oriented network services (CONS) and connectionless network services (CLNS). In CLNS mode, COTP4 offers various features including flow control between peer transport entities, detection and recovery from packet loss, duplication, corruption and out-of-sequence delivery via segment and acknowledgment numbering. Furthermore, COTP4 relies on the retransmission timeout mechanisms to detect packet loss and uses the Go-Back-N protocol when retransmitting packets. For air-ground subnetworks, COTP4 protocol implementations must support configurable values for protocol parameters and timers [3].

Congestion on network nodes can cause delays in data transmission and result in data loss. Therefore, to provide end-to-end reliability, the congestion control is one of the key features of transport protocols. In ATN/OSI, the router adds an explicit congestion notification (ECN) to the packet when experiencing congestion. The COTP4 receiving entities rely on ECN to detect congestion. The sending rate, known as advertised window size, is defined and updated by the receiving entity. This advertised window size determines the amount of segments a sender can transmit before waiting for acknowledgment. It is initially set to 1 and updated when the total number of segment received corresponds to the possible advertisement of a new window size. It should be incremented by adding 1, if the number of segments received with ECN is less than 50% of the total number of the segments received. Otherwise, the advertised window size is reduced by multiplying it with a window decreasing factor that ranges from 0.75 to 0.95 [3]. Then, the receiving entity sends the updated window size in the acknowledgment to the sending entity. The advertised window size is used to send the subsequent segments. It is worth to note that the choices made in COTP4 are the opposite of those made in the Internet with the TCP protocol: explicit congestion notification versus implicit congestion detection, determination of the transmission window by the receiver versus calculation of this window by the transmitter.

2.2.1 ATN/IPS transport layer requirements

Currently in the standardisation phase, the ICAO 9896 document [5] specifies some considerations for the IPS architecture. It includes the connection-oriented TCP per RFC 793 [Reference Postel15] and RFC 1323 [Reference Jacobson, Braden and Borman16], and the connectionless UDP per RFC 768 [Reference Postel17] as transport protocols. TCP ensures reliability, whereas UDP is connectionless and lightweight. The primary benefit of TCP over UDP is that it guarantees the delivery of all data. However, TCP, on the other hand, does not offer any control over delivery time delays. The primary drawback of TCP compared to UDP is overhead. The UDP header is 8-bytes long and for TCP the header is between 20 to 60B.

The ICAO document [5] also requires the use of IPS Dialogue Service (IPS DS) on top of the transport protocols for the existing applications in ATN/OSI, as shown in Fig. 3. The IPS DS is an IP adaptation layer which helps the legacy applications to use TCP and UDP without any necessary modifications. However, the IP DS is not required for native IP applications to operate with TCP and UDP. The general IP internetworking for ATN/IPS is based on IPv6 per RFC 2460 [Reference Deering and Hinden18].

Figure 3. ATN/IPS protocol stack.

2.2.2 TCP congestion control mechanisms

TCP is the second transport protocol proposed in 1981 [Reference Postel15]. TCP is one of basic protocols of the Internet protocol suite to provide reliable communications in connection-oriented mode. Since its release, different TCP variants were introduced by aiming to improve the congestion control mechanism. This later is one of the most important transport protocol roles. These TCP variants include RENO, New Reno, CUBIC, BBR and etc [Reference Polese, Chiariotti, Bonetto, Rigotto, Zanella and Zorzi19]. What these transport protocols have in common is the use of the Karn and Jacobson algorithms, introduced in RFC 6298, to compute the retransmission delay. The New Reno version enhances the TCP congestion control mechanism presented in RFC 5681 by improving its fast recovery algorithm, as described in RFC 6582. Moreover, CUBIC [Reference Rhee, Xu, Ha, Zimmermann, Eggert and Scheffenegger20] and QUIC [Reference Iyengar and Swett21] protocols can be perceived as TCP enhancements using congestion control algorithm based on New Reno. Due to its wide deployment and representativeness of how congestion control should operate, this work focuses on the evaluation of the TCP New Reno congestion control algorithm for ATN/IPS.

TCP New Reno is one of loss-based transport protocols using additive increase and multiplicative decrease (AIMD) algorithm for the congestion control [Reference Mascolo and Grieco22]. This AIMD algorithm main objective is to either increase or decrease the flow sending rate based on events occurring on the sender entity. TCP New Reno is well known to represent how a congestion control mechanism should work. Therefore, in this study, TCP New Reno is considered for the future ATN/IPS applications. TCP New Reno has three different key features to manage congestion, such as slow start, congestion avoidance, and fast recovery. In this protocol, the sender defines its congestion window (cwnd) before sending the numbered segments. The cwnd is initially set based on the sender maximum segment size (SMSS) value. For instance, if SMSS is less than or equal to 1095B, the initial cwnd size should be set to 4*SMSS [Reference Allman, Paxson and Blanton23]. In the other side, the receiver indicates its window (rwnd) size while establishing the transport connection. Then, the inflight size is defined by the minimum value between cwnd and rwnd. The sender entity uses this inflight size to limit the amount of segment can be sent before receiving an acknowledgment (ACK). During the slow start and congestion avoidance phases, the sender analyses the acknowledgments of the previously sent data to detect the network load.

During the slow start phase, the sender increases exponentially its cwnd size when a new data ACK is received. The congestion avoidance phase starts when the cwnd size reaches the slow start threshold (ssthresh). In this phase, the cwnd size continues to increase linearly. The three duplicated ACKs receipt is considered as a sign of packet loss which starts the fast recovery phase. In this phase, the oldest in-flight segment is retransmitted and the ssthresh is updated to half of the inflight size. It remains in this phase until the acknowledgment of all segments in flight from the same window size. When this phase ends, cwnd is multiplicatively reduced and the sender enters the congestion avoidance phase. A retransmission timeout (RTO) is considered as a link failure, which updates the ssthresh to half of the inflight size, and resets the cwnd and inflight size to 1 SMSS. Then, the slow start phase increases the cwnd size up to ssthresh, as shown in Fig. 4.

Figure 4. Evolution of cwnd size in TCP New Reno.

4.2.1 Scenario 1: CPDLC message exchange from pilot to controller

This scenario focuses on pilot sending messages to controller with maximum block size of 10 and 50B. The SMSS of the transport protocol is set to 500B. Figures 10 and 11 present the message end-to-end delay with block size of 10 and 50B. With the block size of 10B, the data flow increases because each massage is fragmented. Figure 10 indicates that the medium-period of lossy congestion has less effect on the delay for both CTOP4 and TCP. However, during the short-period of lossy congestion, the end-to-end delay increases up to 17 and 21s in long-period congestion for CTP4. Contrarily to COTP4, for TCP, the lossy congestion periods does not highly affect the end-to-end delay which increases to around 2.3s. When the data flow decreases with the maximum block size of 50B, during the lossy short and medium congestion periods, the end-to-end delay slightly increases to 2 and 1.9s for COTP4 and TCP, respectively. During the long period of lossless congestion, the end-to-end delay for COTP4 increases up to around 5.2s, as shown in Fig. 11.

Figure 10. Messages end-to-end delay for block size of 10B.

Figure 11. Messages end-to-end delay for 50B block size.

When the block size is set to 10B, we have the overhead ratio plotted in Fig. 12. It can be seen that the header is between 45% to 90% of the COTP4 segment size against 69% to 95% with TCP transport protocol. However, with 50B block size, the payload size is larger than the overhead for both COTP4 and TCP, as illustrated in Fig. 13. In this case, the header ratio decreases to 15% with COTP4 and 29% with TCP.

Figure 12. Overhead analysis for 10B block size.

4.2.2 Scenario 2: File transmission from ground-to-board

According to the files size considered in this scenario, the SMSS is set to 1kB for the transport protocols. Figures 14 and 15 display the end-to-end delay of files transmission with COTP4 and TCP while using medium-rate file generator, respectively. The important data flow leads from packet loss to each congestion period in this scenario. As shown in Fig. 14, the end-to-end delay increases to around 6s when packet loss occurred during the short and medium congestion periods. Then, the long-period of lossy congestion highly affects the end-to-end delay, which increases up to around 125s. It keeps increasing even when the congestion period is over. For TCP, Fig. 15 demonstrates that, the end-to-end delay increases slightly during the short and medium lossy congestion periods. The delay increases to 10.8s during the long-period of lossy congestion.

Figure 13. Overhead analysis for 50B block size.

Figure 14. Files end-to-end delay with COTP4 for medium-rate generation.

Figure 15. Files end-to-end delay with TCP for medium-rate generation.

With the high-rate file generator, the end-to-end delay increases continuously before, during and even when the congestion period is over with COTP4, as shown in Fig. 16. Contrarily to COTP4, with TCP, the short and the medium lossy congestion periods lightly affects the end-to-end delay, which increases to around 7s, as indicated in Fig. 17. Then, it increases up to 19.5s during the long-period lossy congestion. However, the delay decreases to 3s when the congestion period is over.

Figure 16. Files end-to-end delay with COTP4 for high-rate generation.

Figure 17. Files end-to-end delay with TCP for high-rate generation.

For the case of files size between 5 and 10kB, and SMSS set to 1kB, we have the header ratio plotted in Fig. 18. It is noteworthy that the header ratio versus the payload size varies from 1 to 1kB. Then, it decreases from 90% to 5% with TCP against 47% to 1% for COTP4.

Figure 18. Overhead analysis with COTP4 and TCP packets.

4.3.1 Performance analysis for CPDLC messages exchange

Figures 19 and 20 show how COTP4 control the congestion when the maximum block size is set to 10 and 50B. During the congestion periods, the window size decreases because of the received packet amount with ECN in the receiving entity. A packet loss occurred at 52.14s of simulated time, as indicated in Fig. 19, the end-to-end delay increases to 3s. Because the window size corresponds to 8 segments and the in-flight packets are greater than 1 segment, the lost packet is retransmitted when new acknowledgment received. The retransmission timer T1 is rescheduled so there is no retransmission timeout. A second packet loss occurred at 81.66s, the window size is continuously decreasing and the lack of acknowledgment causes timer T1 to expire. Then, the window size is blocked into 1 segment until the end of the congestion period which prevents to benefit from the Go-Back-N mechanism in COTP4. This congestion increases promptly the end-to-end delay up to 17s. Furthermore, Fig. 20 demonstrates that during a lossless congestion period, the ECN receipt decreases the window size continuously. As result, the end-to-end delay increases because of window size blocked into 1 segment and not because of packet loss.

Figure 19. COTP4 congestion control analysis for 10B block size.

Figure 20. COTP4 congestion control analysis for 50B block size.

During congestion period analysis different cases were identified in Fig. 21 when using TCP as the transport protocol. The first case consists of delayed transmission at the start of the congestion period, which causes the RTO timer to expire at 51s before the packet reaches its destination, as seen in Fig. 21. Then, the end-to-end delay increases, as shown in Fig. 10, and the ssthresh decreases to half of the inflight size as stated in Fig. 21. The second case is that a packet loss occurred at 61.02s, the RTO timer expires at 62.12s before receiving any duplicate ACK, which increases the end-to-end delay. Last case, after receiving three duplicate ACKs, TCP enters the fast retransmit phase. However, the reception of duplicate ACKs and the packet retransmission during the fast retransmit phase do not satisfy the conditions for restarting the retransmission timer and leading to an RTO. Figure 22 also shows that the packet retransmission relies only on RTO expiration. In these different cases, TCP considers delayed transmission and isolated loss as link failures. This leads to a degradation of TCP performance, which is inline with the studies presented in Refs [Reference Ehammer, Gräupl and Rokitansky25, Reference Muhammad, de Cola, Kissling and Berioli27].

Figure 21. TCP congestion control analysis for 10B block size.

Figure 22. TCP congestion control analysis for 50B block size.

In the continental airspace, with the RCTP of RCP 130 presented in Table 1, the required end-to-end delay corresponds to 10s (TT/2). The COTP4 performance respects the expected delay with the maximum block size of 50B but not with 10B. However, despite the overreaction during the congestion control, TCP New Reno respects the required end-to-end delay with both block size of 10 and 50B.

4.3.2 Performance analysis for files transmission

In terms of congestion control, Figs 23 and 24 illustrate the behaviour of COTP4 and TCP with medium-rate file generator. For COTP4, the advertised window size increases normally until the start of the short-period congestion, as shown in Fig. 23. Then, the window size decreases because of the receipt of ECN in the receiving entity, and when it reaches the value of 1 segment, the end-to-end delay increases. With the medium-period of lossy congestion, the end-to-end delay is slightly affected because the advertised window size is still large enough for COTP4 to benefit from the Go-Back-N mechanism. However, when the window size is stalled into 1 segment, the end-to-end is dramatically affected, as displayed in Fig. 14. Figure 24 demonstrates the efficiency of TCP New Reno congestion control mechanism while operating with medium-rate file generator compared to COTP4. When isolated loss occurred during the short and the medium congestion periods, the receipt of duplicated ACK decreases the ssthresh to half of the inflight size. Then, when the sender receives three duplicated ACKs, it enters the fast recovery phase. The ssthresh is updated to half of the inflight size and the cwnd is set to ssthresh + 3 SMSS. As result, the end-to-end is lightly affected by these packet losses. However, during the long-period of lossy congestion, TCP experiences three RTOs timeouts at 551, 592, and at 600s of the simulated time followed by the slow start phases. These RTOs timeouts are caused by the loss of two packets belonging to the same cwnd. The packets are retransmitted during the fast recovery phase; nevertheless, the receipt of duplicated ACKs and this retransmission type do not restart the retransmission timer. As result, RTO expires before new packet is acknowledged. The end-to-end delay increases for the second packet loss due to the time required to receive its duplicated ACK. This is normal behaviour for TCP New Reno.

Figure 23. COTP4 congestion control analysis for medium-rate generator.

Figure 24. TCP control analysis for medium-rate generator.

Figure 25 shows an abnormal congestion control of COTP4 with high-rate generator. The advertised window size is rarely updated compared to the supposed flow of files generated. The window size increases normally before the short-period lossy congestion starts. During the congestion periods, the window size is blocked to one value for a while then it decreases or increases. It results the drastic increase of the end-to-end delay in Fig. 16. For TCP, similarly to the result with medium-rate generator, the congestion control in Fig. 26 displays its efficiency.

Figure 25. COTP4 congestion control analysis for high-rate generator.

Figure 26. TCP control analysis for high-rate generator.

The packet losses during the short and medium congestion periods lightly affect the end-to-end performance because of the fast recovery feature. The RTO timeouts occurred because of two-packet loss from the same cwnd. This is handled in the exact identical way as the packet loss in medium-rate generator.

This files transmission analysis demonstrated that the congestion control mechanism used in COTP4 is unsuitable for applications transmitting flows of data. However, the TCP New Reno congestion control mechanisms can efficiently manage massive and high-rate data transmission for the future ATN/IPS applications. In contrast to the approach proposed in the RASP protocol [Reference Muhammad, de Cola, Kissling and Berioli27], these results demonstrated the necessity of flow and congestion control in handling the data flows of future ATN applications.

5.1.1 Loss detection and flow control

For CPDLC application, the sender attributes a sequence number for each outgoing segment. The receiving entity sends an acknowledgment for the received segment with the next expected segment number. In terms of flow control, a stop and wait mechanism is appropriate due to the low rate of messages exchange with CPDLC. This mechanism relies on RTO timer to detect UDP datagram loss. The RTO expiration requires a packet retransmission, with a maximum retry of three times. The segmentation and reassembling are necessary for packet with size greater than 500 B.

5.1.2 Congestion control mechanisms

CPDLC is a time-sensitive application and to respect the RCP requirements, the use of RTT-based congestion control algorithm would be efficient. Due to robust RTT estimation and RTO back off handling, Karn’s algorithm [Reference Karn and Partridge32] has prevented unnecessary retransmission from turning into link failure for decades for TCP. However, the RTO retransmission timer, which only uses measured RTTs when there are no retransmissions, as required by the Karn’s algorithm, results in unnecessary retransmissions. The binary exponential back off, $RTT{\rm{*}}2$ , used in TCP does not correctly handle unnecessary retransmissions when the RTT is greater than the RTO, as in the case with CPDLC.

Due to the similarity of data flow in CPDLC with the IoT field, a standardised IoT approach will be used for the RTT estimation. In IoT, various congestion control algorithms were introduced to improve the end-to-end reliability mechanism for constrained application protocol (CoAP). Fast-Slow RTO (FASOR) is one of the proposed algorithms and is in standardisation phase, last updated in 2023 [Reference Jarvinen, Kojo, Raitahila and Cao33]. FASOR aims to provide a trade-off between aggressive and conservative retransmissions logic using a self-adaptive retransmission timer. This technique avoids introducing extra delay with unnecessary retransmissions and reduces flow completion time under link errors. To achieve these objectives, FASOR considers the unambiguous and ambiguous RTTs to update its retransmission timer. The unambiguous RTT is measured from packet that receives an ACK without retransmissions. While an ambiguous RTT is derived from the original transmission of the packet until the receipt of the ACK, regardless of the number of retransmissions.

Figure 27. Proposed end system protocol stack for ATN/IPS.

Table 2. ATN applications required features

5.1.3 RTO estimation

To correctly infer losses and avoid making unnecessary retransmissions of data still existing in the network, the RTO must be longer than the actual RTT. FASOR, as specified in Ref. [Reference Jarvinen, Kojo, Raitahila and Cao33], is composed of three key components including FastRTO computation, SlowRTO and innovative retransmission timer back off logic. The FastRTO calculation is based on the TCP RTO computation (RFC 6298) [Reference Paxson, Allman, Chu and Sargent34], with an upper bound of 60s and without minimum RTO bound, using unambiguous RTT sample. Allowing RTO values lower than 1s can improve latency for low RTT environments. SlowRTO has been developed to ensure that only one copy of the message is transmitted before at least one RTT has elapsed. SlowRTO is computed by multiplying the ambiguous RTT by a factor, set to 1.5 by default. To reduce the impact of SlowRTO in cases where RTOs occur for reasons unrelated to congestion, FASOR uses retransmission timer back off logic.

FASOR back off logic has three states that are from the least conservative to most conservative such as FAST, FAST_SLOW_FAST, and SLOW_FAST, as shown in Fig. 28. After receiving ACK without retransmissions, the FASOR sender always stays in or transits back to the FAST state. If an ACK is received only after retransmissions, FASOR switches to a more conservative state of FAST_SLOW_FAST until it reaches the SLOW_FAST state, where it remains as long as completing a message exchange requires retransmissions.

Figure 28. FASOR back off logic state machine.

In this way, situations with link errors will be improved by using the back off with the unambiguous RTT-based RTO, and heavy congestion cases will benefit from the systematic use of ambiguous RTT-based RTO [Reference Jarvinen, Kojo, Raitahila and Cao33].

5.2.1 Loss detection and flow control

The future ATN/IPS applications are expected to send large data flows. Hence, for data larger than the SMSS, segmentation and reassembling must be performed. The SMSS value should be set in accordance with the maximum transmission unit (MTU) of the network, which excludes the TCP/IP headers and options. Similar to CPDLC, each outgoing segment must have a sequence number to enable the recognition of its respective acknowledgment. The receiver uses the sequence number to reorder segments as well as detect out of range segment. To notify the sender of an out-of-range receipt, the receiving entity sends an ACK with next expected sequence number for the missing segment until it is delivered. As result, the sender entity receives duplicate ACKs, which are then used to detect loss.

In terms of flow control, the sliding window protocol will be used along with cumulative ACK. The RTO expiration is considered as an indication of link failure. The segments will then be retransmitted using the Go-Back-N protocol. The maximum number of segment transmissions is limited to three.

5.2.2 Congestion control mechanisms

The performance analysis in Subsection 4.2 demonstrates that the loss-based congestion control mechanism adopted by AIMD transport protocols like TCP New Reno is suitable for the considered future application. As described in Ref. [Reference Allman, Paxson and Blanton23], this TCP protocol considers segment loss as sign of network congestion.

The initial congestion window size should be defined based on the SMSS value and the cwnd update must meet the standards outlined in Ref. [Reference Allman, Paxson and Blanton23]. The high-rate data transmission expected in the future applications can benefit from New Reno features. It includes the slow start phase, the congestion avoidance phase, and the fast recovery mechanism in the event of isolated segment loss [Reference Henderson, Floyd, Gurtov and Nishida30].

5.2.3 RTO estimation

When the sender does not get an acknowledgment from the receiver, it should rely on the retransmission timer to ensure data delivery. The retransmission timer, called RTO timer, should be computed using Jacobson’s algorithm, as outlined in Ref. [Reference Jacobson35]. The RTT samples used to calculate RTO should meets the requirements of Karn’s algorithm [Reference Karn and Partridge32]. It only considers RTT samples derived from segments that were not retransmitted. The retransmission timer should be managed based on the algorithm defined in Ref. [Reference Paxson, Allman, Chu and Sargent34]. It avoids the retransmission of a segment in less than one RTO after its previous transmission. When the RTO timer expires, segments that have not been acknowledged should be retransmitted. Then, the sender must update the RTO timer using the binary exponential back off value of RTO * 2. A maximum value of 60s may be used to provide an upper bound, as introduced in Ref. [Reference Paxson, Allman, Chu and Sargent34].