TCP Stratos for stratosphere based computing platforms

Abstract

Stratosphere computing platforms (SCPs) benefit from free cooling but face challenges necessitating transmission control protocol (TCP) re-design. The redesign should be considered due to stratospheric gravity waves (SGWs), and sudden stratospheric warming (SSWs). SGWs, and SSWs disturb the wireless channel during SCPs packet communications. SCP packet transmission can be done using existing TCP variants at the expense of high packet loss as existing TCP variants do not consider SGWs, and SSWs. TCP variants designed for satellite links are not suitable as they do not explicitly consider the SSW, and SGW. Moreover, the use of SCPs in future internet is at a nascent stage. The presented research proposes a new TCP variant i.e., TCP Stratos. TCP Stratos incorporates a parameter transfer mechanism and comprises loss-based; and delay-based components. However, its window evolution considers the occurrence of SSWs, and SGWs. The performance benefit of the proposed approach is evaluated via MATLAB numerical simulation. MATLAB simulation has been used because of the consideration of the stratosphere. The modelling of the stratosphere in this case is challenging for conventional tools and frameworks. Performance evaluation shows that using TCP Stratos instead of existing TCP variants and improved TCP variants reduces the packet loss rate by an average of (7.1–23.1) % and (3.8–12.8) %, respectively. The throughput is enhanced by an average of (20.5–53)%, and (40.9–70)% when TCP Stratos is used instead of existing TCP variant and modified TCP variant, respectively.

Introduction

The transmission control protocol (TCP) enables packet communications. It was initially designed for wired networks and later re-designed for wireless networks as seen in Yun [1], Kocan et al. [2], and Zeng et al. [3]. TCP has been further re-designed to support satellite networks in Wang et al. [4], Nguyen et al. [5], and Akyildiz et al. [6]; and cognitive radio networks in Luo et al. [7], Byun [8], and Hassani et al. [9]. A re-design is deemed necessary for future networks in Poorzare et al. [10], Rico et al. [11], and Gao et al. [12], and Tataria et al. [13]; and cloud computing platforms in Artuso et al. [14], Zheng et al. [15], and Lee [16].

Cloud computing service providers are now considering the realization of environment friendly operations in designing and deploying data center facilities by Google (https://cloud.google.com/blog/topics/sustainability/google-cloud-region-picker-helps-you-make-the-green-choice), Amazon (https://aws.amazon.com/compliance/data-center/environmental-layer/), and Microsoft (https://docs.microsoft.com/en-us/compliance/assurance/assurance-datacenter-environmental-safeguards). The need to reduce data center operational cost has necessitated the use of non–terrestrial data centers located in the underwater as observed by Microsoft (https://news.microsoft.com/innovation-stories/project-natick-underwater-datacenter/; https://natick.research.microsoft.com/), Reuters (https://www.reuters.com/markets/commodities/chinas-guangdong-province-plans-move-data-centres-undersea-cut-power-use-2021-12-14/), and Subsea Cloud (https://www.subseacloud.com/); space in Periola et al. [17], Kua et al. [18], and Au [19]; and stratosphere in Kurt et al. [20]. In Kurt et al. [20], the stratosphere is identified as being suitable for freely cooling data centers because it is a low temperature environment. The temperature in the stratosphere is observed to lie in the range − 15^OC to -50^OC as seen in Kurt et al. [20]. These locations offer free cooling and reduced cooling cost benefits.

Additional research as regards TCP re–design for stratosphere-based computing platforms is required. The research presented in this paper identifies the challenges associated with re–designing TCP for stratosphere computing platforms. This is due to the peculiarity of the transmission challenges in the stratosphere i.e., the occurrence of stratospheric gravity waves, and sudden stratospheric warmings. The focus of the paper identifies with the approach used in Poorzare et al. [10]. The discussion in Poorzare et al. [10] outlines the challenges associated with using TCP in 5G networks. It identifies and discusses the challenges that need to be addressed for a seamless use of TCP in 5G networks. Furthermore, it identifies machine learning as being capable of enhancing TCP performance in 5G networks. The discussion in [10] is set in the perspective of designing an architecture for TCP in 5G networks. The context in Poorzare et al. [10] focuses on the terrestrial long-term evolution (LTE) network. However, unlike [10], the discussion here identifies the challenges associated with packet communications in the stratosphere for different contexts. These contexts are realized via different stratosphere disturbance events. The research presented here extends Poorzare et al. [10] in three different aspects. In the first aspect, it considers the use of TCP in the near space stratospheric environment instead of the terrestrial environment in Poorzare et al. [10]. Second, the research in Poorzare et al. [10] identifies the useful potential of machine learning for enhancing TCP in terrestrial networks. The presented research extends the discussion in Poorzare et al. [10] by applying machine learning solution to enhance TCP being used in the stratosphere environment. Third, the research in Poorzare et al. [10] considers TCP being used in a subscriber context. However, the presented research extends Poorzare et al. [10] by considering a non–terrestrial data center (i.e., Stratosphere based data center) context.

The use of the stratosphere presents a solution to provide computing platform driven solutions to regions without significant maritime resources in a low-cost manner (as compared to accessing outer space). Therefore, the stratosphere computing platforms (SCP) is beneficial in ubiquitous computing networks.

Contributions: The proposed research addresses the challenge of designing a new TCP variant for the SCP. The re-design is necessary because of the need to consider the need to achieve packet communications in SCPs. SCPs are new nodes in wireless networks and the internet. The consideration of the SCP from a perspective of TCP re-design is required because new effects affect the packet transmission in the stratosphere environment. The contributions of the paper are further enumerated as:

• (1) First, the paper proposes TCP Stratos, a TCP variant designed considering stratospheric turbulence and disturbing events such as gravity waves in the stratosphere as seen in Hoffmann et al. [21], Wen et al. [22], Podglajen et al. [23] and Eichinger et al. [24]; and stratospheric warming in Hauchecorne et al. [25]. Stratospheric gravity waves (SGWs) and sudden stratospheric warmings (SSWs) pose challenges to the SCP wireless channel. SGWs have been observed to arise due to the effects of mountain ridges with sufficient width on moving strong wind as seen in Nappo [26]. The SGWs involves vertical transport of energy accompanied by particle movement. The occurrence of SGWs is supported by a background wind. The discussion by Nappo [24] explores the occurrence of different mountain geometries. The considered mountain shapes are three–dimensional, gaussian, and bell. The occurrence of SGWs i.e., essentially movement of wave energy supported by background wind result in the movement of particles. In the stratosphere, the occurrence of internal gravity waves influences particle transport. The discussion by Podglajen et al. [23] presents a theory whose underlying concept is that the occurrence of gravity waves influences particle transport in different atmospheric regions. An important and applicable atmospheric region is the stratosphere as seen in Podglajen et al. [23]. The stratosphere hosts a significant number of particles and has different trajectories as seen in Eichinger et al. [24]. The discussion in Podglajen et al. [23] and Eichinger et al. [24] explains that there is particle movement in the stratosphere. The particle movement is influenced by the occurrence of gravity waves. Gravity waves in the stratosphere i.e., SGW have a wind signature with particles moving in a characteristic manner. The discussion in Podglajen et al. [23] and Eichinger et al. [24] is set in the context that the SGW moves a large number of heterogeneous particles. The general movement of a large number of heterogeneous particles disrupts the line of sight required for wireless communications. The line-of-sight disruption occurs due to particle accretion in the stratosphere due to the influence of SGWs. The occurrence of particle accretion leads to the occurrence of large sized particles that disrupt line of sight. The line-of-sight disruption affects data communication on the channel that enables SCP data transmission. The disruption of line of sight on the wireless channel causes data loss. In addition, SSWs results in a case where the stratosphere is unable to provide free cooling to the SCP. In a case where the SCP migrates to a new location with free cooling capability, the occurrence of SGWs due to this migration leads to data loss. In addition, the channel conditions in the new location with support for free cooling alongside the occurrence of SGWs are potential causes for data loss necessitating packet re-transmission. It is important to re–design TCP to consider the occurrence of these events in the process of packet communications associated with SCP related wireless communications. SGWs and SSWs are localised to the stratosphere and influence packet communications in SCP-to-SCP communications. Their awareness is developed via the incorporation of meteorological information elements into TCP Stratos. The proposed solution considers the occurrence of SGWs and SSWs with a duration between 30 min and 4 h [22].

• (2) Second, the paper presents a mathematical model describing TCP Stratos window evolution via parameter transfer in developing the values for the coefficients and parameters used in TCP Stratos. The parameter transfer process describes the use of the behaviour of TCP Compound during packet communications to infer and derive the values for the parameters influencing packet communications in TCP Stratos. In the paper, a model for TCP Stratos is derived. However, the value of the parameters in the model is derived via parameter transfer. The presented research also formulates the performance benefits of TCP Stratos. The metrics of interest are the packet loss rate, and the throughput. The performance benefits of TCP Stratos are investigated for these metrics via MATLAB simulation.

In this paper, TCP Stratos design is done with the aim of identifying challenges and providing a framework. This is considered sufficient for the SCP at this nascent stage. Currently, there is yet to be an identification of factors that influence packet communications in the transport layer protocols in SCP packet communications.

The rest of the paper is organized as follows. “Motivation section” section presents the motivation for the presented research. The discussion in “Motivation section” section discusses how the research problem is necessitated by the existing research. “Background and existing work” section and “Proposed solution – TCP variant: TCP Stratos” section discusses the background work and proposed TCP Stratos, respectively. “TCP Stratos: model development” section presents the model underlying the behaviour of TCP Stratos. “Performance formulation” section formulates the performance model. The formulated metrics are packet loss rate, and throughput. The discussion in “TCP Stratos: model development” section further evaluates the performance benefits of the proposed variant TCP Stratos. In “Performance evaluation” section, the analysis of the simulation results is also presented. The conclusion of the research focusing on the presentation of the proposed TCP Stratos is presented in “Conclusion” section.

Motivation section

The focus of this section is the presentation of the existing work in the aspect of addressing challenges related to transport functionality in different communication networks. The discussion here builds on “Introduction” section i.e., the Introduction via the consideration of more literature in the area of existing solutions focusing on transport level solutions for communication networks. It serves the function of examining the relevance of the proposed solution from the perspective of solutions that have been presented in existing research. The existing work that has been considered are [27,28,29,30].

The discussion by Sharma et al. [27] addresses the challenge of congestion control in mobile ad-hoc networks. The need to separately consider the mobile ad-hoc network is because of its higher complexity than infrastructure-based networks. The proposed solution explicitly focuses on realizing an adaptive medium access control layer with the added benefit of improving the channel utilization. The focus and perspective in the presented solution is that an explicit need to re-design the transmission control protocol variant may not be necessary when network complexity or scenario significantly increases and changes. Such a design approach may not be suitable in a new wireless environment such as the underwater, space or near space.

The challenge of selecting the path with the best quality of service in a multi-path packet transmission scenario is addressed by Sharma et al. [28]. The path selection is done considering the loss rate, buffer, and bandwidth associated with each path. In addition, the information and data associated with the medium access sub-layer is considered. Essentially, the discussion in Sharma et al. [27] presents an intelligent and adaptive cross-layer solution for the highly dynamic mobile ad-hoc network. The presented solution focuses on using parameters at Layer 2 and Layer 3 for the cross-layer solution. A similar cross-layer driven algorithm with focus on the use of Layer 2 and Layer 3 based parameters can be found Sharma et al. [28].

The use of cross-layer based mechanisms to improve packet transmission in wireless networks is recognized to be suitable for complex networks. The mobile ad-hoc network is recognized as an example of a complex and highly dynamic network scenario. The perception in Sharma et al. [27,28,29] is that the packet transmission can be enhanced without changing the TCP variant at the transport layer. This assumes that the maximum segment size does not contravene the data handling capacity of protocols at the medium access control sub-layer. The challenge should be addressed as Sharma et al. [27,28,29] have focused on Layer 2 and Layer 3.

In a data center, it is important to re-design the TCP as recognized by Ousterhout [30]. This is recognized for the data center as a network. However, the data center node has not been considered by Sharma et al. [27,28,29]. In Ousterhout [30], and Zhu et al. [31], the data center is in a terrestrial environment. In such a case, the TCP re-design process has not considered the objective of reducing terrestrial data center cooling costs. However, TCP re-design for a non-terrestrial data centre such as a stratosphere-based data center addresses packet communications while achieving free cooling (with reduced operational costs) (Table 1). The differences in the motivation for TCP re-design as the transition occurs from terrestrial data center to the SCP arises from three areas. These areas are:

Table 1 Underlying difference necessitating TCP re-design in stratospheric computing platform

The discussion presented in this section provides the motivation for the design of a TCP variant for the SCP. The SCP is a new network node on the internet when integrated into communication networks. It plays the role of enabling data access, data storage, and the execution of data forwarding. Furthermore, the discussion identifies the peculiarities of the stratosphere and the use of high-altitude platforms. These peculiarities provide a basis that necessitates TCP re-design for the SCP. The role of the SCP is crucial for enabling the access of data in underserved regions. In such a case, the SCP enables data forwarding.

The next two sections proceeds as follows. The next section i.e., “Background and existing work” presents the existing work on TCP design perspectives. The following section i.e., “Proposed solution – TCP variant: TCP Stratos” presents the proposed solution i.e., TCP Stratos intended for use in SCPs that act as network nodes that enable data access via content forwarding.

Background and existing work

Mast et al. [32] present a layer 4 based congestion control mechanism for wireless ad-hoc networks. The cross-layer solution being presented involves the joint functioning of the transport layer and the data link layer. The transport layer functionality prevents or limits the occurrence of buffer overflow alongside congestion window adaptation to limit the occurrence of packet loss in the network. The congestion window receives information from the medium access control sub layer to indicate the occurrence of congestion in the network. In the proposed solution, each node in the wireless ad-hoc network computes the number of attempts that has been made to access the channel. Each node estimates a moving average to indicate the number of attempts in this regard. The data transmission in the concerned wireless ad-hoc network enables TCP to acquire awareness of the occurrence of contention on the channel. In the proposed cross layer mechanism, TCP acquires awareness of the occurrence of congestion via the moving average computed at the medium access control sublayer by each node in the wireless ad-hoc network. Therefore, it can be inferred that the wireless ad-hoc network event that influences the occurrence of congestion and congestion window adaptation is the occurrence of channel contention. Channel contention is influenced by the presence of a significant number of nodes in the wireless ad-hoc network.

An adaptive congestion control mechanism is presented by Mishra et al. [33], addresses the challenge of designing TCP for the case of a network of internet of vehicles. The cross-layer approach presented in this case is similar to that presented in Mast et al. [32]. The similarity arises in that both the data link layer and the transport layer share information with each other. The inter-layer information sharing enables the adaptation of the buffer space and link utilization. In the proposed solution, the congestion window size is adapted via a consideration of the channel utilization and buffer space. In comparison to Mast et al. [32], the discussion considers the case of a new network application i.e., internet of vehicle case. The approach in Mast et al. [32], and Mishra et al. [33], present an approach where a congestion and channel contention logic are implemented at the medium access control layer to influence the congestion window adaptation.

The discussion in Buenrostro–Mariscal et al. [34] proposes the design of an end-to-end congestion control mechanism for the case of internet of things deployed in health applications. The network being considered is the internet of medical things. The proposed solution called the priority–based congestion layer protocol (QCCP) provides the capability of cross layer congestion control. In a medical application, priority of the transmitted information is deemed to be important. Packet priority is considered for each application as a main criterion for the execution of data forwarding and delivery. The interaction between the transport layer and the medium access sublayer is considered in implementing congestion control and packet prioritization. The inter–layer communication is enabled via the service access point in the IEEE 802.15.4.2006a standard. The inclusion of packet prioritization in Buenrostro–Mariscal et al. [34] differentiates the cross-layer solution design from the system in Mast et al. [32], and Mishra et al. [33].

Xu et al. [35] present a new perspective to improve the performance of network transport protocols such as TCP. The new perspective is the experience driven design approach. The proposed experience driven design approach is recognized to build on the availability of network data. In the proposed solution, a cross layer approach has not been significantly pursued. Instead, the machine learning approach of reinforcement learning is designed for the approach of model–free control. The discussion in Buenrostro–Mariscal et al. [34] recognizes that the existing approaches in improving TCP performance in communication networks requires the availability of a closed form expression i.e., mathematical model. The closed form expression describes the mathematical model of the network being enhanced. Such a position does not significantly consider the occurrence of network behaviour and complexities that cannot be modelled in closed form expressions. The occurrence of this scenario and case is significant considering the increase in complexity due to the use of network systems in diverse contexts.

In comparison to the research in Mast et al. [32], Mishra et al. [33], and Buenrostro–Mariscal et al. [34], Xu et al. [35] describe how the use of the machine learning approach can significantly enhance the end-to-end congestion control in evolving networks. Network evolution involves the interaction between previously isolated network applications. The concerned interaction leads to scenarios leading to an interplay between different underlying algorithms. Such interaction leads to scenarios that have not been considered in the previous network architecture. In addition, the discussion in Ousterhout [30], Zhu et al. [31], Mast et al. [32], and Mishra et al. [33] has considered the context of designing a transport protocol (end to end congestion solution) for terrestrial networks. This is because of the test environment and non-specific concern of the challenges that arise with the consideration of non-terrestrial networks. A similar approach to the use of machine learning to enhance TCP performance (loss-based) with focus on mobile ad-hoc networks in Molia et al. [36].

The discussion in Mast et al. [32], Mishra et al. [33], and Buenrostro–Mariscal et al. [34] presents different approaches enabling the enhancement of TCP in different network scenarios such as internet of vehicles, internet of medical things, and wireless ad-hoc networks. The presented solutions utilize closed form expressions that enable the emergence of data describing network behaviour. The obtained data can be used to develop data driven solutions that is suitable in cases where the use of closed form expressions is inapplicable due to non-availability. The incorporation of a machine approach in TCP design enables the inclusion of a data driven plane into future TCP models. However, the use of TCP has been mostly considered in the context of terrestrial communication networks.

The focus of designing TCP with emphasis on terrestrial network entities as seen in Mast et al. [32], Mishra et al. [33], Buenrostro–Mariscal et al. [34], Xu et al. [35], and Molia et al. [36] has been extended to the case of terrestrial data center and computing platforms. A terrestrial data center and computing platform focused TCP redesign is presented in Tsai et al. [37], and Balasubramanian et al. [38]. However, the discussion in Tsai et al. [37], and Balasubramanian et al. [38] focuses on the enabling of packet communications and does not consider other data center operational goals. An important goal in this regard is the reduction of cooling costs (operational cooling costs). The goal of cost reduction can be realized by placing data centers in non–terrestrial locations. An example of a supporting non-terrestrial location with free cooling capability is the stratosphere by Yang et al. [39].

The discussion by Yang et al. [39], describes the mechanisms underlying stratospheric cooling effect. In Yang et al. [39], the stratospheric cooling event is deemed to be occurring under the influence of global warming. The stratospheric cooling event is recognized to arise due to the effect of radiative and non–radiative processes. The discussion by Yang et al. [39], presents a complete radiative model. In relation to the presented research, the discussion in Yang et al. [39], demonstrates that the occurrence of global warming does not influence the sustainability of stratospheric cooling. Therefore, the long-term use of stratosphere cooling in relation to realizing the SCP is feasible. The use of the stratosphere is beneficial in comparison to that of the cold regions in space. This is because of the associated low launch costs.

However, the environment of the stratosphere presents new effects that needs to be considered by the TCP being incorporated aboard a stratosphere-based data center. This challenge has not been addressed in Tsai et al. [37], and Balasubramanian et al. [38] and requires research consideration because of the effects of the SGWs as seen in Podglajen et al. [23] and Eichinger et al. [24] and SSWs Hoffmann et al. [21].

The discussion in the next section presents the design approach for a TCP Variant (proposed) suitable for the stratosphere-based data center i.e., the stratosphere computing platform (SCP).

Proposed solution – TCP variant: TCP Stratos

The focus of the research is the design of a novel TCP variant intended for use in the SCP as a network node enabling content access on the internet. The SCP engages in communications with gateway entities enabling content access based on the preferences of the internet subscribers. The novel TCP variant functions as the transport layer protocol of the SCP. The basis for the re-design of the TCP and presenting TCP Stratos lies in the peculiarities of the stratosphere environment and the need to consider SGWs, and SSWs. The events of SGWs, and SSWs influence the stratospheric channel thereby affecting the packet communications and forwarding in the new network segment of the internet comprising the SCP.

The discussion in this section presents the proposed TCP Stratos. Being placed at the stratosphere in an aerial location exposes the SCP to physical risks. In addition, the integration of the SCP into the internet for packet forwarding makes it susceptible to cybersecurity related attacks. However, the SCP being mobile has an inherent benefit in that being mobile makes it challenging to know its location. Platforms such as the SCP have a dynamic location making it challenging for their physical location to be known. This improves the physical security and enhances their resilience to cyber–attacks as signal interception is challenging.

In this case, it is important to make the SCP immune against cybersecurity threats. The proposed TCP Stratos is deployed aboard the SCP. The SCP engages in inter–SCP communications, uplink with ground stations and downlink with ground stations. In the downlink and uplink, the SCP being a near space entity benefits from the same solutions as used in existing satellite communications. Suitable robust security solutions can be found in Periola [40], Koroniotis et al. [41], and Moustafa et al. [42]. The terrestrial ground station constitutes the main point of attack and benefits from the solutions in Koroniotis et al. [41], and Moustafa et al. [42]. Existing research as seen in Sridharan et al. [43], Lorincz et al. [44], and Al–Saadi et al. [45] has considered TCP performance in different contexts. However, an explicit consideration of the SCP requires further attention.

The rest of the discussion presents TCP Stratos and has two aspects. The first aspects describe the intelligent aspect i.e., dynamics and adaptive logic enabling the consideration of SGWs and SSWs. The second aspect focuses on the proposed intelligent solution incorporated in TCP Stratos.

TCP Stratos: response and logic to SGWs and SSWs

In the context of TCP Stratos, this section presents aspects associated with SGWs, and SSWs. The focus of the discussion in this aspect is to present the components of the solution that ensure an incorporation of the events of the SGWs, and SSWs that occur in the SCP. These events are considered from the perspective of addressing the challenges caused by their occurrence on packet communications.

The development of TCP Stratos involves the integration of information on the occurrence and severity of SGWs and SSWs in the stratosphere. Initially, the concerned SCP incorporates information on stratospheric locations where SGWs and SSWs occurrence are likely and highly expected. The concerned information fields are: (1) Stratosphere location coordinates, (2) Stratosphere altitude, (3) Expected start epoch of SGWs and SSWs, and (4) Expected stop epoch of SGWs and SSWs. The required information fields can be obtained via the prediction of the occurrence of SGWs and SSWs. The research in Eckermann et al. [46], Dornback et al. [47], Kaifer et al. [48], Song et al. [49], Gray et al. [50], and Tsvetkova et al. [51] describes solutions enabling SGWs prediction. Similar climate prediction models can be used to forecast the occurrence of SSWs and obtain the identified information elements as seen in Eckermann et al. [46], Dornback et al. [47], Kaifer et al. [48], Song et al. [49], Gray et al. [50], and Tsvetkova et al. [51]. The existence of forecasting models as seen in Eckermann et al. [46], Dornback et al. [47], Kaifer et al. [48], Song et al. [49], Gray et al. [50], and Tsvetkova et al. [51] provides a framework for extracting the identified information elements. The design of TCP Stratos is shown in Fig. 1. In Fig. 1, the transport layer comprises two fields. These are the window evolution stratospheric profile (WESP). The WESP incorporates the meteorological information fields related to SGW and SSW forecasting. In Fig. 1, each layer engages in bi–directional communications with the preceding layer. However, only the TCP sublayer engages in communications with the associated layers in the communication stack shown in Fig. 1. The WESP sublayer communicates with the TCP layer.

Fig. 1

Proposed transport layer incorporating TCP Stratos

The relation between the WESP subcomponent for the TCP at the transport layer is shown in Fig. 2. The scenario in Fig. 2 populates the WESP in two steps i.e., static and the dynamic steps. In the static step, pre–configured data on the determined values for the identified information elements is provided in the WESP static sublayer (WSS). Another layer, the WESP dynamic sublayer (WDS) hosts information elements and receives new values for (the information elements) to execute an update. An update becomes necessary when the content of the WSS is deemed not to correctly reflect the status of the stratosphere.

Fig. 2

Subcomponent of the transport layer in the proposed TCP Stratos

The relations in Fig. 2 shows the role of WSS and WDS in influencing the TCP window evolution. The WSS enable the initial determination of the window increment for TCP Stratos. The window increment in this case is prior to the SCP making connections to the ground based meteorological entity. The window increment does not consider SGW occurrence after SCP deployment (in a manner specific to the SCP). Instead, the window increment considers the prediction of the SGW and its influence in a test phase. The WSS hosts the window increment values that are pre–determined for the SCP. In this case, the window increment is applicable before the SCP receives prediction results from the ground based meteorological entity. The window growth is important as it considers the state of the stratosphere before SCP deployment.

In Fig. 2, the WDS influences the window evolution based on the stratosphere’s meteorological state. The WDS becomes active after SCP deployment and establishing communications with the terrestrial meteorological station. In the WDS, the SCP receives information on SGW occurrence and their influence on TCP window evolution. The ground based meteorological entity observes and acquires data on SGW occurrence. The terrestrial meteorological station hosts machine learning mechanisms that predict SGW occurrence. Algorithms such as this can be found in Wu et al. [52]. The machine learning algorithm in Wu et al. [52] predicts the potential energy of gravity waves. This translates to predicting SGW potential energy in TCP Stratos. The gravity wave potential energy is related to the gravity wave intensity. An high SGW potential energy indicates a high SGW activity and intensity Wu et al. [52]. A high SGW intensity indicates significant particle movement. This implies disruption to the line-of-sight communications between SCPs. In this case, the WDS reduces the TCP window increment. A representation of the WDS, and WSS with relation to communication with the ground based meteorological station is presented in Fig. 3.

Fig. 3

SCP in the WSS and WDS stages

The components of the WESP static and WESP dynamic sublayers are compared to establish similarity in the stratosphere’s profile at different epochs. The comparison is done to determine the necessity of obtaining information in the WDS. A similarity of the stratosphere’s profile implies that the initial content in the WSS is used to determine TCP Stratos’s window evolution. The flowchart showing the execution of tasks in the WESP and TCP layers making use of inference based on meteorological information fields is shown in Fig. 4.

Fig. 4

Packet communications in the TCP Stratos showing the role of WDS, and WSS

Proposed mechanism – intelligent mechanism incorporated in TCP Stratos

A consideration of the effects of SGWs, and SSWs on TCP Stratos should be accompanied by solutions associated with packet transfer and acknowledgement. In this regard, it is important to specify the roles of the WDS, and the WSS in the window evolution.

TCP Stratos includes a mechanism to enable the incorporation of the duration associated with the execution of packet transfer and acknowledgement. The WDS is designed with the goal of ensuring that the window evolution considers the state of the stratosphere. It obtains new information elements from the ground based meteorological entity. This approach is subject to high latency associated with data transmission. It is important to consider the case where multiple cloud computing providers deploy multiple SCPs to benefit from free cooling due to the cold environment of the stratosphere. The case of multiple SCPs is considered in the proposed intelligent solution incorporated in TCP Stratos. The TCP Stratos intelligent solution makes use of the latency associated with inter–SCP packet communications. Let $\alpha$ be the set of latency values i.e., round trip time associated with packet communications such that:

$$\alpha=\left\{{\mathrm\alpha}_1,{\mathrm\alpha}_2,\dots,{\mathrm\alpha}_{\mathrm I}\right\}$$

(1)

The values in $\alpha$ are those observed when the WSS influences TCP window evolution. The expected values of the round-trip time (RTT) denoted ${\alpha }_{ave}$ is:

$$\alpha_{ave}=\frac1{\left|\mathrm\alpha\right|}\sum\limits_{i=1}^I\alpha_{\mathrm i},\alpha_{\mathrm i}\epsilon\alpha$$

(2)

In addition, let $\beta$ be the set of RTT values associated with packet communications in the WDS such that:

$$\beta=\left\{\beta_1,\;\beta_2,\dots,\beta_I\right\}$$

(3)

The expected values of the RTT denoted ${\beta }_{ave}$ is given as:

$$\beta_{ave}=\frac1{\left|\beta\right|}\sum\limits_{i=1}^I\beta_{i},\beta_{i}\epsilon\beta$$

(4)

Given a non–significant change in the stratosphere’s environment state and associated wireless channel, it can be expected that:

$$\left|\beta_{ave}-\alpha_{ave}\right|\approx\gamma_{drift}$$

(5)

where ${\gamma }_{drift}$ is the tolerable shift in the average RTT between the phases of the WSS and WDS. The proposed TCP Stratos intelligence mechanism is operational when:

$$\left|\beta_{ave}-\alpha_{ave}\right|>\gamma_{drift}$$

(6)

The proposed TCP Stratos intelligence mechanism executes a packet probing strategy when (6) holds true and no meteorological entity is detected by the SCP. However, the SCP detects a neighbour SCP in the stratosphere. In the TCP Stratos intelligence mechanism, the SCP transmits probing packets to a neighbour SCP and observes the RTT. Let $\phi$ denote the set of RTT values observed in this case such that:

$$\phi=\left\{\phi_1,\phi_2,\dots,\phi_J\right\}$$

(7)

The expected i.e., average observed increased RTT $\phi_{ave}$ is obtained as:

$$\phi_{ave}=\frac1{\left|\phi\right|}\sum\limits_{j=1}^J\phi_j,\phi_{\mathrm j}\epsilon\phi$$

(8)

The parameter $\phi_{ave}$ is used as the waiting time for the successful receipt of the acknowledgement for a transmitted packet. The TCP window size is maintained at its original size when the TCP Stratos intelligence mechanism is activated. The TCP Stratos intelligence mechanism is functional within the WDS sublayer as shown in Fig. 5.

Fig. 5

Transport layer structure showing the incorporation of the TCP Stratos intelligence mechanism

TCP Stratos: model development

The focus of the previous section i.e., “Background and existing work” is the presentation of TCP Stratos design. The discussion presents how TCP Stratos responds to SGWs, and SSWs. The window evolution in TCP Stratos is discussed in this section. This is done with the aim of identifying how the occurrence of the SGWs, and SSWs influences an increase or decrease in the window (congestion window) of TCP Stratos. It extends the discussion in “Background and existing work” section which focuses on aspects related to protocol design with relation to TCP Stratos.

The discussion here presents the mathematical model for window evolution in TCP Stratos. The window evolution in TCP Stratos and is given as:

$$W_t=W_{t-1}\left(1+\sum\limits_{n=1}^2\gamma_{n}\theta_{t-1}^n+\theta_{t-1}^3\right),t\geq1,\theta_{t-1}^1+\theta_{t-1}^2+\theta_{t-1}^3=1$$

(9)

$W_t$ and $W_{t-1}$ are the window sizes i.e., the congestion window associated with TCP Stratos at the epoch $t$ and $t-1$, respectively. In (9), the initial window size given by $W_0$ is obtainable when $t=1$.

$\gamma_1$ and $\gamma_2$ are the weighting factors associated with the window size (the congestion window) due to the experience of lost packets (loss–based) associated with the receipt of acknowledgements and long latency (delay–based) associated with the experience of large RTT values during packet transmission, respectively.

$\theta_{t-1}^1$ and $\theta_{t-1}^2$ are the window (the congestion window) increment factors associated with the weighting factors $\gamma_1$ and $\gamma_2$, respectively. The values of the congestion window associated weighting factors i.e., $\theta_{t-1}^1$ and $\theta_{t-1}^2$ is positive when window growth is deemed necessary. Negative values of the congestion window weighting factors are deemed necessary where a drawback in the window growth is deemed appropriate.

$\theta_{t-1}^3$ is the window (the congestion window) increment factor due to the occurrence of SGWs and SSWs. The value of the window increment $\theta_{t-1}^3$ is important for the WSS, and WDS. In the context of the WSS, the value of $\theta_{t-1}^3$ is pre-determined and made available in TCP Stratos as the SCP is deployed. In this case, the value of $\theta_{t-1}^3$ is determined based on SGW and SSW observation during the SCP deployment planning phase. The WSS hosts a varying value of $\theta_{t-1}^3$ determined via a consideration of the prediction output of the machine learning algorithm from the meteorological ground station.

Furthermore, the values of $\theta_{t-1}^3$ can be positive or negative. A positive value of $\theta_{t-1}^3$ enables the increase in the window size when a significant number of transmitted packets are acknowledged. This arises in the case where wireless channel conditions support high throughput. Negative values of $\theta_{t-1}^3$ are deemed appropriate when a significant number of packets are not acknowledged after a given duration. In this case, the packet loss occurs due to the occurrence of SGWs, and SSWs.

The determination of the parameters $\gamma_n{,\theta}_{t-1}^m,n\epsilon\left\{\text{1,2}\right\},m\epsilon\{\text{1,2},3\}$ is done via parameter transfer process. TCP has been recognized to benefit from machine learning as seen in Weinstein et al. [53]. In this case, the SCP observes the window evolution in TCP Compound because it supports loss and delay-based components.

The variation in the values of $\theta_{t-1}^1,\theta_{t-1}^2,$ and $\theta_{t-1}^3$ describe the network profile associated with the SCP in different contexts. These contexts are: (1) Context 1 – In this case, all transmitted packets are acknowledged within an expected round trip time. Furthermore, there is no occurrence of SSWs, and SGWs. The profile is: $\theta_{t-1}^n<\theta_t^n<\theta_{t+1}^n,\dots.<\theta_{t+p}^n,n\{\text{1,2},3\}$. (2) Context 2 – In this case, there is a packet loss while there is low network delay i.e., latency associated with packet communications by the SCP. The profile is: $\theta_{t-1}^1>\theta_t^1>\theta_{t+1}^1,\dots.>\theta_{t+p}^1,$$\theta_{t-1}^n<\theta_t^n<\theta_{t+1}^n,\dots.<\theta_{t+p}^n,n\left\{\text{2,3}\right\}$. (3) Context 3 – The case here is one in which there is significant delay leading necessary adjustment and reduction in the delay-based window component $\theta_{t-1}^2$. The profile is: $\theta_{t-1}^2>\theta_t^2>\theta_{t+1}^2,\dots.>\theta_{t+p}^2,\theta_{t-1}^n<\theta_t^n<\theta_{t+1}^n,\dots.<\theta_{t+p}^n,n\left\{\text{1,3}\right\}$, and (4) Context 4 – The considered scenario is one having significant channel disturbance due to the occurrence of SGWs and execution of SSWs. The profile is: $\theta_{t-1}^n>\theta_t^n>\theta_{t+1}^n,\dots.>\theta_{t+p}^n,n\{\text{1,2},3\}$.

The SCP determines the values of the coefficients $\theta_{t-1}^1,\theta_{t-1}^2,$ and $\theta_{t-1}^3$ considering the predicted severity of stratosphere related events as obtained from the ground–based meteorological station. The values of these coefficients are determined by the SCP in the WDS stage. The rationale for the determination of the values of these coefficients and their concerned value relations is presented in Table 2. The relations presented in Table 2 show the range of values of the coefficients $\theta_{t-1}^1,\theta_{t-1}^2,$ and $\theta_{t-1}^3$ for different stratosphere contexts. Four contexts are considered i.e., normal stratosphere, nominal stratosphere, mild stratosphere, and severe stratosphere contexts. In specifying these contexts, it is assumed that the

Table 2 Specification of the values of the window coefficients considering different stratosphere contexts

The specification of the value of the coefficients $\theta_{t-1}^1,\theta_{t-1}^2,$ and $\theta_{t-1}^3$ is done generically considering the SGW potential energy. The SGW potential energy is observed in Wu et al. [52] to influence the SGW intensity. The SGW potential energy will have varying values for different locations. Hence, the specification presented in Fig. 1 considers a generic approach. In the case of a normal stratosphere context, the observed SGW potential energy falls below the average of the predicted value samples. The occurrence of SGW is deemed not to significantly influence the SCP packet transmission. Hence, the specified value of the coefficient is the same as that in (9). In the case of the nominal stratosphere context, the each of the coefficients has a value that is less than 1, but the sum of all the coefficients is less than 1. The TCP window increment is less than that obtainable for the normal stratosphere context as the influence of SGW begins to receive consideration. For the case of the mild stratosphere context, the SGW potential energy slightly exceeds the average SGW potential energy. In this case, the SGW window–related coefficient, $\theta_{t-1}^3$ is slightly negative such that the sum of $\theta_{t-1}^1,\theta_{t-1}^2,$ and $\theta_{t-1}^3$ is approximately zero. This implies a significant reduction in the window increment and a gradual reduction in the window size. The reduction in the window size is deemed necessary to reduce packet loss. The observed SGW potential energy for a given number of samples significantly exceeds the observed average in the severe stratosphere context. In this case, the SGW window related coefficient i.e., $\theta_{t-1}^3$ is also negative and falls short of zero. Furthermore, the sum of the coefficients $\theta_{t-1}^1,\theta_{t-1}^2,$ and $\theta_{t-1}^3$ in this case is negative and not approximately equal to zero. This implies that a sudden reduction of the TCP window size is deemed necessary when severe SGWs occur.

The SCP utilizes TCP Compound and TCP Stratos with the window evolution in (9). Initially, the SCP utilizes TCP Compound with the observed delay–based and loss–based window increment values are used to develop values of $\theta_{t-1}^2$ and $\theta_{t-1}^1$, respectively. In the first phase, $\theta_{t-1}^3$ is negative. This provides a drawback on the rapid window growth in consideration of the new environment of the stratosphere. The meta–cognition process achieves TCP Stratos parameter transfer via:

• 1. Phase 1: Parameter Test and Value Derivation Phase – In this phase, the TCP Compound logic is deployed in the TCP stack of the SCP for executing packet communications. The window growth role associated with the delay–based and loss–based components are used as the values of $\theta_{t-1}^2$ and $\theta_{t-1}^1$ for the delay-based congestion window and the loss-based congestion window, respectively. The associated weighting factors obey the relation given as $\gamma_2>\gamma_1$ and $\gamma_1>\gamma_2$ if $\theta_{t-1}^2<\theta_{t-1}^1$ and $\theta_{t-1}^1<\theta_{t-1}^2,$ respectively. In this case, the value of $\theta_{t-1}^3$ is according to the relation ${\theta }_{t-1}^{3} \le 0$. This is considered to prevent excess window growth leading to packet loss.

• 2. Phase 2: Value Transfer and Model Testing Phase –Phase 2 involves developing the values of the parameters associated with TCP Stratos in (9). The mean values (expectation for $\theta_{t-1}^2$ and $\theta_{t-1}^1$) observed in Phase 1 i.e., Parameter Test and Value Derivation Phase are transferred to the corresponding values in TCP Stratos. The mapping is executed as follows: The delay window and loss window component in TCP Compound corresponds to $\theta_{t-1}^2$, and $\theta_{t-1}^1,$ respectively. The weighting factors $\gamma_1$ and $\gamma_2$ are determined in a random manner. The value of $\theta_{t-1}^3$ is negative if a high packet loss is observed, and positive if there are no packet loss events.

• 3. Phase 3: TCP Stratos Test and Fine Tuning: TCP Stratos executes packet communications in this phase. In phase 3, the parameters transferred in phase 2 are used to execute packet transmission in TCP Stratos. The value of the parameters is tuned via an exploration process involving packet communication between two SCPs. The formalization of TCP Stratos’s windows evolution parameters and their associated values is executed in the second stage under this phase.

The relation between the three identified phases is shown in Fig. 6. Figure 6 shows the relations and the associated parameter values being transferred between the concerned phases.

Fig. 6

Relations between the three phases in TCP Stratos

The discussion in this section i.e., “Proposed solution – TCP variant: TCP Stratos” presents aspects related to the window evolution in TCP Stratos. Phases associated with different stages in the congestion window evolution process have been identified and inter–phase relations are also discussed. An important task that is addressed in the presented research is formulating TCP Stratos performance and investigating its performance benefits. The performance formulation and investigation of TCP Stratos are important concerns that are addressed in “Performance formulation” section and “Performance evaluation” section , respectively.

Performance formulation

The formulation of TCP Stratos performance model plays an important role in enabling the investigation of its performance model. The discussion here formulates the performance model of TCP Stratos. It also formulates the performance model of an existing TCP variant and a modified TCP variant. In the context of the performance formulation, an existing TCP variant is a TCP variant that has been designed for use in wired networks without the incorporation of features or support for packet communications in later wireless networks. Furthermore, the modified TCP variant is one that is designed for use in wireless communication networks but without the incorporation of the mechanisms proposed for TCP Stratos. The modified TCP variant is identified to be suitable for use in SCPs. However, its performance is challenged by the occurrence of the identified effects of SGWs, and SSWs as it does not incorporate meteorological information elements as seen in TCP Stratos. In formulating the performance model, the discussion here extends “Proposed solution – TCP variant: TCP Stratos” section by using the presented design capabilities in formulating a performance model that considers different metrics. The considered metrics are the packet loss rate, number of lost packets, and the throughput associated with inter–SCP packet communications.

The use of TCP Stratos aboard the SCP is intended to reduce the packet loss rate and the number of lost packets in inter–SCP communications. The performance metrics being formulated to evaluate the performance of TCP Stratos are the packet loss rate and number of lost packets. These metrics are deemed importance to determine the performance of a connection-oriented transport layer protocol such as the TCP.

The metrics are formulated considering that TCP Stratos is operational in five phases. These phases are: (1) Window Phase 1: Packet transmission initialization, (2) Window Phase 2: Window size near maximization phase, (3) Window Phase 3: Window size maximization phase, (4) Window Phase 4: Onset of Stratospheric disturbance phase and (5) Window Phase 5: Peak of Stratospheric disturbance phase. The incorporation of Windows Phase 4, and Windows Phase 5 arises due to the inclusion of meteorological information elements in TCP Stratos. The operational duration in Window Phase 1 (WP 1), Window Phase 2 (WP 2), Window Phase 3 (WP3), Window Phase 4 (WP 4) and Window Phase 5 (WP 5) at the epoch $t_{\mathrm y},t_{\mathrm y}\epsilon t,t=\{t_1,t_{2,}\dots,t_{\mathrm Y}\}$ are denoted $\varsigma_1\left(t_y\right),\varsigma_2\left(t_y\right),\varsigma_3\left(t_y\right),\varsigma_4\left(t_y\right)$ and ${\varsigma}_{5}\left({t}_{y}\right)$, respectively. The packet transmission rate associated with ${\varsigma}_{1}\left({t}_{y}\right), {\varsigma}_{2}\left({t}_{y}\right), {\varsigma}_{3}\left({t}_{y}\right), {\varsigma}_{4}\left({t}_{y}\right)$ and ${\varsigma}_{5}\left({t}_{y}\right)$ are denoted $\varphi_1\left(t_y\right),\varphi_2\left(t_y\right),\varphi_3\left(t_y\right),\varphi_4\left(t_y\right)$ and $\varphi_5\left(t_y\right)$, respectively. In TCP Stratos, the packet loss rate,  is given as:

(10)

${\mathcal{f}}_{u}\left({t}_{y}\right), u{\epsilon} \{\text{1,2},\text{3,4},5\}$ is the fraction of packets acknowledged in the corresponding phase at the epoch ${t}_{y}$. The value of the fraction is such that ${\mathcal{f}}_{u}\left({t}_{y}\right) \le 1.$

In (10), the terms ${{\mathcal f}_4\left(t_y\right)\varphi}_4\left(t_y\right)\varsigma_4\left(t_y\right),$ and ${{\mathcal f}_5\left(t_y\right)\varphi}_5\left(t_y\right)\varsigma_5\left(t_y\right)$ describe the packet transmission by TCP Stratos in the window phases WP 4, and WP 5. These terms are present in (10) as the proposed TCP variant i.e., TCP Stratos engages in packet communications in window phases WP 4, and WP 5.

For the case of the existing TCP variant such as TCP New Reno presented in Piotrowska et al. [54], the phases WP 4 and WP 5 are not considered in the protocol operation. This is because TCP New Reno does not incorporate meteorological information elements as found in the WESP (and its sublayers of the WSS, and the WDS). Hence, the occurrence of the stratospheric disturbances results in the non–receipt of acknowledgement for transmitted packets. The TCP variant considered in this case is the loss–based TCP variant, TCP New Reno. The variant TCP New Reno is loss based as seen in Poorzare et al. [10]. In this case, the packet loss rate,  for TCP New Reno (including phases WP4 and WP 5) is:

(11)

In (11), the terms ${{\mathcal f}_4\left(t_y\right)\varphi}_4\left(t_y\right)\varsigma_4\left(t_y\right),$ and ${{\mathcal f}_5\left(t_y\right)\varphi}_5\left(t_y\right)\varsigma_5\left(t_y\right)$ are absent. This is because TCP New Reno is not designed to execute packet communications in the SCP considering SGW. Hence, TCP New Reno is not operational in the window phases WP 4, and WP 5.

The case of a resilient TCP connection by an existing TCP variant is also considered. The concerned TCP variant could be any existing TCP implementation such as TCP Cubic, TCP Compound or TCP New Reno Atxutegi et al. [55]. The considered TCP variant in this case also does not incorporate meteorological information elements as found in the WESP (and its sublayers of the WSS, and the WDS). In this case, there is a capability to ensure packet transmission and acknowledgements during inter–SCP communications. In this case, the resilient TCP variant is identified to be TCP Compound. This is because TCP Compound is deemed better than TCP Reno. The rationale for this is that TCP Compound incorporates an hybrid approach as seen in Poorzare et al. [10]. It combines loss–based and delay–based mechanisms. The non–resilient existing TCP variant that is considered is the loss–based TCP Reno. The packet loss rate,  for TCP Compound (including phases WP4, and WP5) is given as:

(12)

The terms ${{\mathcal f}_4\left(t_y\right)\varphi}_4\left(t_y\right)\varsigma_4\left(t_y\right),$ and ${{\mathcal f}_5\left(t_y\right)\varphi}_5\left(t_y\right)\varsigma_5\left(t_y\right)$ are present in (12) indicating packet transmission by the concerned SCP using a resilient TCP variant. In this case, the resilient TCP variant is TCP Compound has limited packet transmission in the window phases WP 4, and WP 5. A limited packet communication capability arises in this case because TCP Compound has not been designed to operate aboard the SCP. In addition, TCP Compound has not been designed to operate in the context of the stratosphere environment.

In (12), the fraction of acknowledged packets during phases WP 4 and WP 5 are increased in comparison to the case in (11) where the terms corresponding to WP 4 and WP 5 are absent. In this case, these terms are given as ${\boldsymbol\theta}_{\mathbf4}\boldsymbol({\boldsymbol t}_{\mathbf y}\boldsymbol)$ and ${\boldsymbol\theta}_{\mathbf5}\boldsymbol({\boldsymbol t}_{\mathbf y}\boldsymbol)$ for the phases WP 4 and WP 5, respectively.

The number of lost packets corresponding to (10), (11) and (12) are denoted ${\boldsymbol\ell}_{\boldsymbol1},{\boldsymbol\ell}_{\boldsymbol2}$ and ${\boldsymbol\ell}_{\boldsymbol3}$, respectively.

(13)

Given that the size of packet at the epoch ${t}_{y}$ is denoted $\xi \left({t}_{y}\right)$, the throughput considering that the communication occurs over the entire duration described by the five phases is denoted ${{\Gamma }}_{q}, q\epsilon \{\text{1,2},3\}$. The throughput corresponding to (10), (11), and (12) are denoted ${{\Gamma }}_{1} ,{{\Gamma }}_{2},$ and ${{\Gamma }}_{3},$ respectively. The formulated throughput is given as:

(14)

The occurrence of packet loss events leads to a case where a high latency arises in the course of completing content transfer. In this case, lost packets have to be re–transmitted being non–acknowledged. The formulation leading to the relations in (10), (11), and (12) enable an inference on the latency based on the packet loss rate. The packet loss rate as formulated in (10) considers the occurrence of SGWs and SSWs in the fourth phase and fifth phase. In this phase, the window evolution recognizes the occurrence of SGWs, and SSWs. In this case, the number of packets and segments are reduced to limit packet loss, and the resulting retransmission (and accompanying latency). The reduction of the window size in phases 4, and 5 in the proposed mechanism serves to reduce the packet loss rate and the number of lost packets. A reduction in the number of lost packets implies the occurrence of a lower incidence retransmitted packets. Given an excellent channel, a low number of retransmitted packets leads to shorter latency in completing data transfer.

The formulation for the case where an improved (i.e., resilient) TCP variant is used has been presented in (12). In this case, the occurrence of phases 4 and 5 are considered. However, this consideration does not consider a variation of the congestion window as indicated in the case of the proposed TCP Stratos. Furthermore, the improved i.e., the resilient TCP variant does not incorporate the use of meteorological information elements as found in TCP Stratos. A proportion of the packets that are transmitted in this phase are acknowledged. Hence, some losses occur as the SCP continues to engage in inter–SCP communications. The case for the use of the existing TCP variant without modification is presented in (11). In (11), the second term has a low value (while being less than one). In this case, the events in phases 4, and 5 have not been considered. Therefore, a high packet loss results leading to the occurrence of high number of re–transmission events with high accompanying latency.

The use of TCP Stratos presented in the formulation shown in (10) also influences the latency associated with the data transfer. The latency in this case is influenced by the occurrence of SGWs, and SSWs related incidences. A long duration SGWs and SSWs lead to the occurrence of reduced window sizes for a long duration. This reduces the number of packets i.e., size of information that can be transmitted via the wireless channel. A reduction in the number of packets that can be transmitted leads to a reduction in the achieved throughput (bits per second). A short duration SGWs, and SSWs enables the transfer of more packets i.e., increased data sizes and window sizes. This is achieved with a reduced number of re-transmissions resulting in low latency.

The discussion has formulated a performance model for the Packet Loss Rate, Number of Lost Packets, and the Throughput. The formulated performance model is useful in investigating the performance benefits of the proposed TCP Stratos with relation to existing TCP variants in different contexts. The discussion in the next section i.e., “Performance formulation” focuses on the performance evaluation. This is done via network simulations.

Performance evaluation

The discussion presents the results of performance evaluation via simulation. This is done using the formulation presented in “Performance formulation” section for the packet loss rate, and the throughput.

The evaluation is done considering three scenarios i.e., (1) Proposed TCP Stratos, (2) Existing TCP Variant i.e., TCP New Reno, and (3) Improved TCP Variant i.e., TCP Compound. The case of the Improved TCP Variant is one in which an existing TCP variant is modified for use in the SCP-to-SCP packet communications context. In the performance evaluation, the considered TCP variants are analysed from the perspective of the SCP packet communications in the stratosphere environment.

The network scenario comprises two SCPs in inter–SCP communications. The inter–SCP communications are executed while the SCP are tasked with data forwarding. In the network scenario, the two SCPs are the nodes in the non–terrestrial network. The topology corresponding to this network scenario is one in which the two SCPs considered have line of sight enabling direct communications. The choice of two communicating SCPs are deemed sufficient as the evaluation aims to investigate the performance benefits of TCP Stratos given the occurrence of SGWs, and SSWs. The effect of the SGWs, and SSWs occur significantly in the stratosphere as compared to downlink and uplink that involve interactions outside the stratosphere.

In the performance evaluation, MATLAB has been used. It is recognized that the ns-3 (with 3 implying the third version of the network simulator suite for research software and tools) simulator is conventionally deemed suitable for simulations of the presented context. In the network simulator − 3 (ns 3), the point-to-point Helper class is suitable for realizing the point-to-point link such as those being considered in the performance evaluation as seen in Riley et al. [56]. The point-to-point Helper enables the specification of the data rate and delay (latency) via the SetDeviceAttribute, and SetChannelAttribute methods, respectively Riley et al., [56]. A determination of the values of the data rate, and delay (latency) to be used in the simulation requires a knowledge of these parameters from the appropriate network standards. The execution of evaluation is challenging as the proposed SCP is yet to be incorporated as non-terrestrial data center nodes in network standards such as the fifth-generation partnership project (5GPP). A standardization with respect to the use of SCPs as nodes in future networks is still a subject of future research. Therefore, an ns–3 based performance evaluation is challenging in this case. Hence, the use of MATLAB. Furthermore, in the simulation and performance evaluation, there is an increasing number of packets being transmitted with increasing epochs.

In addition, the performance evaluation is done considering three cases associated with the duration of the occurrence of SGWs and SSWs i.e., the stratospheric disturbances. The considered cases from the perspective of duration are: (1) Short, (2) Moderate and (3) Long. The set of simulation parameters for the case of short duration, moderate duration and long duration are shown in Tables 3, 4 and 5, respectively. The performance evaluation is not done with the aim of evaluating the window evolution but focusing on the packet loss rate. This is because the overall goal of TCP Stratos is reducing the packet loss rate.

Table 3 Simulation parameters – short duration case

Table 4 Simulation parameters – moderate duration case

Table 5 Simulation parameters – long duration case

The value of the simulation parameters considers the choice of the: (1) Phase Duration, (2) Packet Transmission Rate, and (3) Proportion of Acknowledged Packets. The phase duration values used in the simulation has the lowest mean for the case of a short duration SGW (Table 3), and the highest mean for a long duration SGW (Table 5). The choice of the phase duration simulation parameters is done in a manner that its values exceed the latency for wireless packet transfer. The packet round trip is in the order of tens of milliseconds. A suitable radio link with this latency is realizable for the transmission of 20 GByte of data at a link throughput of 32 Tbps. A high throughput is achievable for HAPs in the Terahertz range as seen in Saeed et al. [57].

The choice of the simulation parameters associated with the phase duration is motivated by the need to ensure that the SGW duration exceeds packet round trip time i.e., packet latency. In the case of the packet transmission rate, the choice of the simulation parameters considers a varying packet transmission rate. Therefore, the value of the packet transmission rate in Tables 3, 4 and 5 is varying. This describes a varying subscriber pattern for accessing data stored aboard the SCP. Therefore, the packet transmission rate is specified in the number of packets transmitted per second. The number of packets transmitted per second is varying, and dynamic. The simulation procedure has not considered the packet size. In the inter–SCP communications context, the packet size is variable and its value can be determined within the context of data center applications.

A dynamic channel in which successful and unsuccessful packet transmission occur has received consideration in the choice of the value of proportion of acknowledged packets. For each of the parameters in Tables 3, 4 and 5, it can be seen that cases with varying proportion of the acknowledged packets has been considered. However, it can be seen that Phase 4, and Phase 5 has the least proportion of acknowledged packets. The rationale for this choice in the simulation is due to SGW influence in packet transmission between SCPs. An exception to this choice of transmission parameters is the proportion of acknowledged packets for Phase 5 in Table 5 (long SGW duration case). In this aspect, the proportion of acknowledged packets is significantly high. This seeming anomaly is deemed important to be considered as the end of the SGW event is being considered. The simulation is done using the relations in (10), (11), and (12) for TCP Stratos, Existing variant (TCP NewReno), and resilient existing variant (TCP Compound), respectively. The existing TCP variants are evaluated from the perspective of their capability to engage in packet communications in the context of SGW. In the simulation, TCP Reno is considered to be least suitable than TCP Compound. This is because TCP Compound being hybrid incorporates loss based and delay-based components in influencing its window evolution process. Such capability is absent in the less robust and non–hybrid TCP Reno which is loss based.

The performance evaluation is done using the simulation parameters presented in Tables 3, 4 and 5. The MATLAB simulation framework has been used in this case. It is challenging to use ns-3 (expected conventional tool) in this case. The challenge arises because of the need to incorporate the duration of each of the considered five phases. Being closely linked to the stratosphere, it is challenging to model the performance evaluation in ns–3. The challenge observed arises because of the non-extensive explicit consideration of the stratosphere in ns-3. In ns–3, information on the meteorological state of the stratosphere is not incorporated.

The evaluation results showing the packet loss rate (%) for the case of a short, moderate, and long duration SGWs and SSWs are examined using the simulation parameters in Tables 3, 4 and 5, respectively. The simulation results showing the packet loss rate for each of the considered epoch of packet transmission for the case of short duration, moderate duration and long duration stratospheric disturbances (SGWs, and SSWs) are shown in Figs. 7, 8 and 9, respectively. In each of these Figures i.e., Figs. 7, 8 and 9; the existing variant, modified variant, and proposed variant are TCP New Reno, TCP Compound and the proposed TCP Stratos, respectively. The identification of the concerned TCP variants is in line with the earlier definition and specification in the relations presented in (10), (11), and (12) as corresponding to TCP Stratos (proposed TCP variant), TCP New Reno (existing TCP variant) and TCP Compound (modified TCP variant), respectively.

Fig. 7

Simulation results showing the packet loss rate (%) for the case of the Short Duration with the simulation parameters shown in Table 2

Fig. 8

Simulation results showing the packet loss rate (%) for the case of the moderate duration with the simulation parameters shown in Table 3

Fig. 9

Simulation results showing the packet loss rate (%) for the case of the long duration with the simulation parameters shown in Table 4

The use of TCP Stratos results in a reduced packet loss rate. For the case of the short duration stratospheric disturbances (SGWs, SSWs), the use of the TCP Stratos instead of existing TCP variant and improved TCP variant (adapted for the case of SCP to SCP communications) reduces packet loss rate by 7.12% and 3.86% on average, respectively.

In addition, in the case of the moderate duration SGWs and SSWs, the use of the TCP Stratos instead of improved TCP variant and existing TCP variant reduces the packet loss rate by 3.79% and 7.22% on average, respectively. Furthermore, the case of long duration SGWs, and SSWs, the use of TCP Stratos instead of improved TCP variant and existing TCP variant reduces the packet loss rate by 12.8% and 23.1% respectively.

The results in Figs. 7, 8 and 9 shows that there is a high packet loss rate due to the occurrence of SGWs, and SSWs. This make it seems that the proposed solution does not have any significant performance benefit and is associated with a negative connotation. However, this is not so because the simulation is conducted from a non–greedy perspective. In all case of the short, medium and long duration simulation, a significant proportion of packets remain unacknowledged in window phases 4 and 5. The events in window phases 4 and 5 are the onset of stratospheric disturbance and peak of stratospheric disturbance phase. The occurrence of a significant amount of lost packets in these phases signify that SSWs have a high intensity of occurrence Hence, the high packet loss rate. From the perspective of wireless channel, the evaluation considers that a poor wireless channel performance in the performance evaluation.

It is observed that an occurrence of the SGWs, and SSWs for a long duration results in a case where packet transmission becomes infeasible with the packet loss rate becoming negative. The occurrence of an infeasible communication context is followed by transition into a context where packet loss rate is zero (due to the non-execution of packet communications) to a context where packet loss increases significantly. In describing phase duration in this case, the notation $\{\varvec{a},\varvec{b},\varvec{c}\}$ is used with $\varvec{a}, \varvec{b},$ and $\varvec{c}$ being the minimum phase duration, mean phase duration and maximum phase duration, respectively. The results for the case {2.1723, 36.7562, 80.3859}, and {8.1604, 43.9412, 81.9412}by Phase 4, and Phase 5, respectively; is presented in Fig. 10.

Fig. 10

Simulation results showing the packet loss rate (%) for the case of significantly long duration (with occurrence of infeasible communications) for the first case

In Fig. 10, the existing variant, modified variant, and proposed variant are TCP New Reno, TCP Compound and the proposed TCP Stratos, respectively. Furthermore, TCP variant identification in this case is in line with the formulated relations in (10), (11), and (12). The mathematical relations presented in (10), (11), and (12) refer to TCP Stratos (proposed TCP variant), TCP New Reno (existing TCP variant) and TCP Compound (modified TCP variant), respectively.

The confidence intervals for the packet loss rate have been evaluated. The 95% confidence interval for the packet loss rate with the existing variant, modified variant, and the proposed variant i.e., TCP Stratos are (85.47–90.56) %, (82.56–87.36) %, and (79.33–83.88) %, respectively. The use of the proposed variant instead of the existing variants and modified variants reduces the packet loss rate by (7.18–7.38) %, and (3.91–3.98) %, respectively. A motivation to evaluate the 95% confidence interval can be found in Verma et al. [58].

The throughput is evaluated for the case of the short duration, moderate duration, long duration and is shown in Figs. 11, 12 and 13, respectively. In the performance evaluation of the throughput, a channel bandwidth of 2.5 GHz has been assumed. A justification for the use of the value of 2.5 GHz as the bandwidth is that inter–SCP communications as is being considered should achieve high channel capacity and link speed. However, it should be noted that the actual frequency range is subject to determination via standardization.

Fig. 11

Evaluation of the throughput for the case of the short duration scenario

Fig. 12

Evaluation of the throughput for the case of the moderate duration scenario

Fig. 13

Evaluation of the throughput for the case of the long duration scenario

In each of the presentedn Figures showing the results on the throughput i.e., Figs. 11, 12 and 13; the existing variant, modified variant, and proposed variant are TCP New Reno, TCP Compound and the proposed TCP Stratos, respectively. The mathematical relations formulated and presented in (14) and developed from the relations in (10), (11), and (12) have been utilized to conduct the investigation and simulation leading to these results. The identification of the concerned TCP variants is in line with the earlier definition and specification in the relations presented in (10), (11), and (12) as corresponding to TCP Stratos (proposed TCP variant), TCP New Reno (existing TCP variant) and TCP Compound (modified TCP variant), respectively.

In addition, analysis shows that the use of the proposed TCP variant enhances the throughput in comparison to the Modified TCP variant and existing TCP variant in the short duration case by 40.9%, and 29.5% on average, respectively. The use of the proposed TCP variant enhances the throughput in comparison to the Modified TCP variant and existing TCP variant in the short duration case by 49.3%, and 20.5% on average, respectively. Furthermore, the use of TCP Stratos enhances the throughput in comparison to the Modified TCP variant and existing TCP variant in the short duration case by 70%, and 53.7% on average, respectively.

In addition, the 95% confidence interval for the throughput evaluation is evaluated and presented using the following notation $\{\varvec{a},\varvec{b}\}$ where a, and b are the lower bound and the upper bound of the 95% confidence interval, respectively. The 95% confidence interval for the throughput in the case of the existing variant, modified variant, and proposed variant for the short duration scenario are {2.889 × 10⁴, 4.353 × 10⁴} Kbps, {3.857 × 10⁴, 5.298 × 10⁴ }Kbps, and {4.814 × 10⁴, 6.313 × 10⁴ }Kbps, respectively. The 95% confidence interval for the throughput in the case of the existing variant, modified variant, and proposed variant for the moderate duration scenario are {2.029 × 10⁴, 3.1822 × 10⁴ }bits per second, {3.433 × 10⁴, 5.020 × 10⁴ }Kbps, and {4.098 × 10⁴, 5.787 × 10⁴ }Kbps, respectively. In addition, the 95% confidence interval for the throughput in the case of the existing variant, modified variant, and proposed variant for the long duration scenario are {2.297 × 10⁴, 3.581 × 10⁴}Kbps, {5 × 10⁴, 7.674 × 10⁴ }Kbps, and {7.419 × 10⁴, 10.516 × 10⁴ }Kbps, respectively. The results obtained from a determination of the 95% confidence interval shows that the use of TCP Stratos enhances the throughput in the cases of the Short, Moderate, and Long Duration.

The discussion in this section presents the results of the performance evaluation with the goal of investigating the performance benefits of the proposed TCP variant i.e., TCP Stratos. The evaluation and the presented results show that the use of TCP Stratos reduces the packet loss rate and enhances the throughput. The metric evaluation is done in the context of packet communications between SCPs in a forwarding mode.

Results highlight

The presented research addresses the challenge of designing a transport layer protocol for a stratosphere based non-terrestrial data centre. In this case, the non–terrestrial data center is a stratosphere computing platform that is located in the stratosphere where it benefits from the free stratospheric cooling. The design of the transport layer protocol is necessary because of the difference presented by the stratosphere environment in comparison to the conventional wireless networks. In the stratosphere, SGWs, and SSWs affect packet communications. A transport layer protocol i.e., the TCP Stratos is presented in this regard. TCP Stratos differs from exisitng TCP variants because of its inclusion of meteorological information elements associated with the SGWs, and SSWs. The inclusion of the meteorological information elements is done to consider the infleunce of the occurrence of SGWs, and SSWs in the TCP Stratos window evolution. Analysis shows that the use of TCP Stratos results in a reduced packet loss rate and an enhanced throughtput. The packet loss rate is reduced by (7.12–23.1)% and (3.8–12.8) % on average when TCP Stratos is used instead of existing TCP variant and improved TCP variant, respectively. Furthermore, the throughput is enhanced by an average of (20.5–53)%, and (40.9–70)% when TCP Stratos is used instead of existing TCP variant (TCP NewReno) and modified TCP variant (TCP Compound), respectively.

Conclusion

The discussion in this paper proposes a new TCP variant, TCP Stratos a connection-oriented transport layer protocol intended to provide reliable packet communications between stratosphere-based computing platforms (SCPs). It is recognized that the role of SCPs is important as free cooling solutions with low cooling operational costs are being sought for future data centers. The use of SCPs is expected to also improve the power usage effectiveness in comparison to existing terrestrial data centers and cloud computing platforms. The presentation of the development of the proposed TCP Stratos benefits from the incorporation of parameter transfer from TCP Compound. The design of TCP Stratos also considers the occurrence of loss, delay, and stratospheric disturbance as having the influence to determine the path of window evolution in TCP. This consideration embodies a design perspective that may be considered for the deployment of TCP in previously unsupported environments. The presented perspective is that the design should be accompanied by an allocation of a congestion window component to the new events that influence congestion window evolution in the considered environment. In addition, the performance evaluation of TCP Stratos is done considering the packet loss rate and throughput as the key metric. Analysis shows that the packet loss rate is reduced by (7.12–23.1)% and (3.8–12.8) % on average when TCP Stratos is used instead of existing TCP variant and improved TCP variant, respectively. Furthermore, the throughput is enhanced by an average of (20.5–53)%, and (40.9–70)% when TCP Stratos is used instead of existing TCP variant and modified TCP variant, respectively. Hence, the use of TCP Stratos is beneficial in the reduction of a packet loss rate in the case of ensuring connection-oriented communications between SCPs.