A new survey on improving TCP performances over geostationary satellite link

,

Seeing that a lot of geographic areas are still uncovered by terrestrial infrastructure networks and due to the fact that geostationary satellite links allow an easy and fast access network for mobile users, such communication systems represent a competitive and adequate solution for Internet access in several contexts. In the last decade, thanks to VSAT (Very Small Aperture Terminal) technologies and recent satellite link access scheme based on DVB-S/RCS (ETSI, 2009), satellite Internet access is getting easier to deploy, less expensive and therefore proposed by an increasing number of service providers.
Nevertheless, it has been often underlined that TCP performances may be affected by satellite links properties such as offered capacity, delay, and bit error rate. A link based on a geostationary satellite induces long propagation delay due to the satellite altitude (about 36,000 km). Furthermore, compared to terrestrial links, these links show high bit error rate, and hence high packet error rate.
Already in the 90's (Partridge & Shepard, 1997;Allman et al., 1997), and a RFC (Allman, 1999) explained how TCP should be tuned and enhanced in order to improve TCP performances in satellite environment. A well-known solution to those problems consists in splitting the end-to-end TCP connection on the satellite link at the ground station. As shown in figure 1, doing so allows the deployment of an enhanced TCP version dedicated specifically to satellite links and their specific properties. These solutions are generally known as TCP PEP (Performance Enhancement Proxy) or TCP accelerator. It has to be noted that PEPs are sometimes implemented at the application level such as proposed in (Davern et al., 2011), where the authors describe a novel HTTP PEP which improve HTTP performances in case of a satellite based Internet access. This particular implementation of PEP is not considered in the present article.  In order to take into account the state of the different links and intermediate  systems between the sender and the receiver, TCP maintains another variable on the sender side named congestion window cwnd. Its value increases when a new acknowledgement indicates that new data is received, and it is decremented on loss detection, for instance when a timer expires. Finally, the amount of data that can be sent before a new acknowledgement, known generally as flight size, is the minimum between these two variables.
The first and most famous enhanced versions of TCP are Tahoe, NewReno and Vegas. These versions and the most recent ones mainly differs in the way they manage the congestion window size and the events or indicators that trigger its updates. The first one has been proposed by Jacobson (Jacobson & Karels, 1988) and introduced the 'fast retransmit' algorithm. Until then, TCP only used a time out based segment loss detection mechanism (i.e. the expiration of a pending timer managed by the sender), Tahoe version enhanced TCP with another way to detect losses based on duplicate acknowledgements. A TCP sender numbers the flow of bytes it receives from the application layer and the receiver periodically acknowledges the data it receives by sending back the number of the expected byte, i.e. the last byte number of the first continuous flow of data received incremented by one.
Tahoe makes the assumption that in the event of duplicate acknowledgement, it has to retransmit the corresponding data even if the timer has not yet expired for these data. In cases of timer expiration or duplicate acknowledgements, Tahoe makes the assumption that the network is congested, and hence decreases its congestion window size to 1 maximum segment size (MSS, a sender network properties defining the maximum size of a TCP segment). With TCP Reno version, Van Jacobson proposed to differentiate these two events in the sense that if timer expiration is symptomatic of a serious problem which justify a drastic decrease of cwnd and hence of the flight size, duplicate acknowledgements revealed a loss followed by the reception of new segments, that is an isolated segment loss. That is why in the second case TCP Reno apply a 'fast recovery' algorithm which consists in dividing the congestion window size by two.
During a nominal behaviour without losses, these TCP versions increment the congestion window size by two mechanisms, Slow Start and Congestion Control. If the flight size is less than a threshold value ssthresh, they use Slow Start and increase cwnd by cwnd = cwnd + 1MSS (maximum segment size) for each acknowledged segment. If the current flight size is greater than ssthresh, during a new phase called Congestion Avoidance the increment is given by cwnd = cwnd + (1MSS/cwnd). The value of ssthresh is half the maximum flight size reached before the last loss detection or equals to rwnd for new connections. NewReno enhance Reno in the sense that after a fast retransmit, the sender stays in fast recovery state until the original window has been entirely acknowledged. Doing so, it improves performances in the case of multiple losses in a same window. In those, relatively old, TCP standards the end-to-end congestion control mechanisms is known as AIMD (additive increase multiplicative decrease) because the TCP sending rate is controlled by a congestion window which is halved for every loss, and increased by one packet per window of data acknowledged.
In the middle of the 1990s, L. Peterson and L. Brakmo researchers at the University of Arizona introduced TCP Vegas offering a new congestion avoidance algorithm (Brakmo et al., 1994). Rather than losses, this algorithm uses the observed packet delay in order to determine the rate at which to send its segments. Of course, this method depends heavily on an accurate calculation of the RTT (Round Trip Time) value which represents the time elapsed between the sending of a segment and the reception of the acknowledgement by the sender. TCP Vegas makes the assumption that under some conditions, an increase in Round-Trip Time reveals a network congestion.

Recent High Speed TCP Variants
More recently, since about 1998, some less known TCP versions have been proposed to accommodate the important growth of the Internet and a mutation of networks links technologies (fibre links, wireless links, ...) and their properties in term of delay and offered capacity. We can cite TCP Westwood, Illinois and BIC as examples of versions which seek to improve performances in case of high bandwidth-delay product networks known also as LFN (Long Fat Networks). Bandwidth-delay product reveals the amount of outstanding data a network can have, and with products higher than 64Kbytes, older TCP versions showed a waste of capacity. That is why, a lot of the newer versions aim at "keeping the pipe full", mainly enhancing packet loss detection and congestion control mechanisms.
For instance TCP Westwood (Casetti et al., 2002) or TCPW exploits end-to-end bandwidth estimation to adjust the values of ssthresh and cwnd after a congestion event. TCPW includes a recovery algorithm which avoids the halving of the flight size following a segment loss in order to ensure a high link utilization even in the presence of errors.

Main Reasons for Splitting End-to-end TCP
One problem of TCP is that it was not originally designed for use over satellite links. As TCP was not designed to be tied with one type or a class of link technology, the downside is that TCP is not optimal on any kind of link. Satellites links represent a kind of medium whose intrinsic specificities may heavily affect TCP performances, especially if one considers equipment and antennas for Internet Access by satellite that are affordable to a large public. Compared to terrestrial networks, those specificities are: • an important propagation delay: about 250 ms considering the altitude of a geostationary satellite • a high bit error rate which can lead to an important PER (Packet Error Rate) considering average packet sizes • a low data rate, with a maximum upload rate of 10 Mbits/s Considering TCP's mechanisms and algorithms, the main causes for TCP's inefficiencies over satellite links are: • 3 way handshake: a TCP connection is established by a "3-Way Handshake" between the receiver and the sender. On satellite links, this may take at least a few seconds to be completed (even for very short data exchanges).
• Receive Window: An application using TCP to send data is only allowed to send an amount of bytes which is explicitly indicated in the last packet sent by the destination. This value known as the "Receive Window", is typically set to about 8 or 16 Kbytes, which severely limits the speeds that a TCP connection can achieve over a satellite.
• Default Slow Start algorithm: As previously explained, TCP starts sending at a very slow rate and increase it until the available capacity is reached. Since this process can take several RTT, the propagation delay inherent to the satellite hop becomes very penalizing. Hence, it will take a long time before TCP reaches its "cruising speed". In some cases, severe packet losses may also generate a drastic TCP behaviour with a new slow start stage.
• Packet loss: Basic TCP assumes that any packet loss is caused by congestion. In order to limit the perceived congestion whenever a packet is lost, TCP generally reduces its congestion window and hence its transmission rate. For instance, TCP NewReno reduced its transmission rate by 50 percent for each detected loss. Of course, because of the bit error rate on the satellite links, packet error rate is observed without congestion occurring. Moreover, because satellite links often acts as bottlenecks considering the difference between satellite and terrestrial links capacity, a lot of packet losses can occur in the considered topology leading to poor TCP performance.
Of course, the idea of adapting existing TCP standards or defining more adequate versions as explained sooner have been explored since the beginning of TCP. Very soon, in 1997, Partridge and Shepard have given accurate recommendation on TCP parameters tuning in order to avoid decrease of TCP performances in case of use in presence of satellite link. The conclusion mainly recommends to adopt new features like window scaling, PAWS (Protection Against Wrapped Sequence number), and Selective Acknowledgement. It must be noted that those enhancements do not represent an exhaustive list of the works done on this subject. Nevertheless, Even if end-to-end TCP performances are better with well tuned TCP parameters, satellite link characteristics still impact performances, in particular the observed delay for a starting TCP connection to fill up the offered capacity.
Furthermore, considering the end-to-end transport protocol approach based on recent high speed TCP variants, we can refer to (Marcondes et al., 2008). This study performs a cross-comparison of equal bandwidth delay product scenarios and very different network topologies based on high-speed networks and satellite networks. The authors experiment with two advanced TCP variants (TCP Westwood and Hybla) aimed at optimizing the throughput and then analyses issues related to improving RTT-fairness and coexistence with standard NewReno.
In another paper (Trivedi et al., 2010), the authors give a comparative performance evaluation of end-to-end TCP Hybla and Cubic on a satellite link and under low error conditions using forward error correction (FEC) techniques. The conclusions of this study are that Cubic performs better than Hybla. In fact, the aggressive cwnd policy adopted by Hybla results in an overall degraded performance in low PER conditions. The authors also explain that the oscillatory behaviour of the cwnd with TCP Hybla would make the performances less predictable, and hence unacceptable for many applications.
Even with the results of those studies, we can observe that satellite link characteristics still impact TCP performances with end-to-end transport protocol. That is why PEP solutions have been and are still proposed and investigated.

Some Details on PEPs
It exists several types of PEPs. As satellite links represent the most challenging environment, they are the main target of PEPs but it is not the only one. Wireless networks more generally may improve their end-to-end performances by implementing PEPs. PEPs may be defined as network agents designed to improve the end-to-end performance. They operate by splitting the end-to-end connection into several successive connections and generally using different protocols for a same layer to transfer data across the different segments. Doing so allows a customization of the protocols without modifying the end systems. A typical implementation uses transport layer PEPs to improve TCP performance over a satellite link. The end systems use standard TCP without even being informed of the existence of the PEP along the link. The PEP is implemented on a router along the TCP connection, when a packet arrives at the router, it is forwarded and the PEP transmits the corresponding ACK to the source host in behalf of the destination host. It also stores a copy of the packet in case retransmission of the packet is required. TCP PEPs are generally placed on each end of a satellite link and are able to send acknowledgements back to the host which has sent segments before the destination host has received them. Border et al. (2001) propose a survey of Performance Enhancing Proxies (PEPs) often employed to improve degraded TCP performance caused by characteristics of specific link environments, for example, in satellite, wireless WAN, and wireless LAN environments. Bisio et al. (2009) gives an overview of PEP mechanisms. As explained, one or more of these mechanisms may be present in a PEP implementation. Considering our objectives, in the case of splitting the end-to-end path in presence of a satellite link in order to implement an alternative adequate transport protocol, we may put the emphasis on three of these mechanisms: • TCP Ack Handling: TCP PEP implementations are generally based on TCP ACK manipulation. For instance, this mechanism allows the PEP to act as a virtual end system hiding from the real end systems that the connection is split. In this case, data segments received by the PEP are locally acknowledged by the PEP.
• TCP ACK Spacing: because of the different capacity on the successive links between end to end systems, burst behaviour may occur on the satellite link. TCP Ack spacing helps with smoothing the flow of Acks and hence of segments.
• Local TCP Retransmissions: As a PEP acts as an end system, it may also locally retransmit data segments lost. Hence, it allows for faster recovery from lost data.
It has to be noted that other important functionalities, such as compression or tunnelling, may play important role in the PEP action.
An important characteristic of PEP concerns its distribution. A PEP implementation can be integrated or distributed. In the first case PEP software is installed on a single point and generally dedicated to satellite Internet access for a single user. In the second case a PEP installation is required on both side of the satellite link in order to share the satellite Internet access between several LAN nodes.
Some examples of PEP solutions are given in (ETSI, 2009). HPEP, which is mostly an HTTP PEP developed by Hughes, uses a distributed asymmetric architecture with a PEP client and a PEP server. HPEP can be considered as an HTTP Proxy. HTTP requests generated by the web client are sent to the Downstream Proxy Server which sends the requests to the Upstream Proxy Server across a single, persistent TCP connection. Doing so, the number of TCP acknowledgements is reduced, thereby reducing the overall traffic over the satellite link and avoiding a waste of resources. Therefore, faster and more efficient Web browsing is expected. But as HTTP is the only protocol supported, other traffics, such as FTP, bypass the proxy and do not get any benefit from HPEP.
I-PEP (Interoperable-Performance Enhancing Proxy) is a splitting architecture proposed by ESA Satlabs. It defines a protocol stack for both side of a satellite link making use of DVB-RCS as access architecture. It aims at improving TCP based applications using SCPS-TP (Space Communications Protocols Standards-Transport Protocol) in order to provide a reliable connection to upper layers on the satellite link. Nevertheless, Roseti et al. (2010) explains that considering the Demand Assignment Multiple Access (DAMA) schemes used to share radio resources in the return channel when DVB-RCS is implemented, protocols at the upper layers may experience an overall delay well above the propagation delay due to an important jitter. Applications based on Transmission Control Protocol (TCP) are particularly affected in such a situation, especially when transferring short objects or files as in the case of Web browsing. In order to avoid this latency and therefore improve performances, a new explained. Then an overview of ETSI BSM is given and different PEP scenarios are described. The conclusions explain that PEPs have the potential to improve TCP and web performances over BSM network.
Again in the context of ETSI BSM reference model, the aim of Giambene and Hadzic (2008) is to consider the problems of TCP performance in broadband GEO satellite networks and to propose a cross-layer approach for a transport layer PEP that makes spoofing actions on acknowledgements to modify them in case of satellite network congestion. The proposed cross-layer signalling allows information exchanges between DAMA (Demand Assigned Multiple Access) implemented in the link layer and TCP in transport layer. Thus this PEP can prevent congestion in the satellite network. This PEP proposal is innovative in the sense that it is non-transparent and requires the application of new cross-layer signalling at both the satellite terminal (ST) and the PEP/gateway. Nevertheless further investigations are needed to fully define the arguments for or against this particular approach.
As described in Caini et al. (2008) an alternative approach arises from the DTN (Delay/Disruption Tolerant Networking) architecture. This architecture is based on the introduction of the new bundle layer in the protocol stack which is inserted between the application and the transport layer. In this new architecture, end-to-end transport protocol features are confined to homogeneous network segments, while real end-to-end data reliability across a heterogeneous network is provided by the bundle layer. The aim of the paper is to discuss the advantages and disadvantages of this approach compared to more conventional solutions. DTN performance is compared with end-to-end NewReno, Hybla and PEPsal. The performances are evaluated by using a testbed. The results show that DTN coupled with TCP Hybla as transport protocol on the satellite segment outperforms TCP NewReno and shows performances close to that achieved by both end-to-end Hybla and PEPsal solutions. Furthermore, by introducing a sliding window, DTN performance is boosted and eventually the best. The DTN solution have been more recently discussed in Caini et al. (2011) which confirms previously observed trends. Furthermore this paper studies DTN security. The advantages over satellite architecture are examined with the threats faced in satellite scenarios, and the open issues. Also, the relation between DTN and quality of service (QoS) is investigated.
Finally, a lot of studies explaining the benefits of PEP solution in satellite context have been proposed. But, as underlined in the introduction and detailed in this section, most of these studies compare PEP solutions with end-to-end ones based on old standard TCP (e.g. NewReno, Vegas). Furthermore, a lot of the PEP studies compare performances of split and end-to-end TCP in a single user topology and even in presence of a single TCP connection. In the same time new TCP flavours, like TCP Cubic, have been proposed and widely deployed in order to match with new links properties, in particular with long high speed links.
We have also to keep in mind that since splitting TCP connection violate end-to-end semantics of TCP, it may present some limits and even drawbacks. For instance, IPSEC which is getting widespread in IP networks in order to provide VPN (Virtual Private Networks) functionality for instance, implies the encryption of TCP headers which is incompatible with PEP deployment since PEP has to access to TCP header without being the authenticated receiver. It has often been concluded, like in Chitre et al. (2004), that the solution to handle TCP protocol inefficiencies over high speed satellite links using the PEP is not applicable in the IPSEC environment. This problem has been investigated, and (ETSI, 2009) already explained that at least through the use of security policies, an end user can select the use of IPsec for some traffic and not for other traffic. In this case, PEP processing can be applied to the traffic sent without IPsec. Another alternative is to implement IPsec over the satellite link between the two satellite gateways where PEPs have been deployed. Even if an end-to-end use of IPsec is not implemented, the traffic between the two PEPs will be protected. Note that in both cases, we do not have a real TCP connection based on end-to-end IPsec encryption and PEPs.

Methodology and Tools
The study presented in this paper is mainly based on the use of a satellite link emulation platform developed at ENAC. This platform allows the emulation of the link capacity, the propagation delay and the packet error rate associated with a satellite link, as well as the jitter induced by access links. In this section, we present the architecture of the emulation platform, as well as the software tools used in our experiments.

(b) TCP traffic generation
To generate TCP traffic, both with HTTP and FTP style flows, we first used two programs named wget (Note 3) and wput (Note 4).
Wget is a tools for retrieving files from HTTP, HTTPS or FTP servers. We chose this tool because it is easy to integrate in shell scripts and thus allows for an easy automation of tests.
Wput is a tool similar to wget but allows for sending to FTP servers and thus was easier to use along with TCPDump on the sender side.
Those tools proved useful, but when we increased the number of TCP connections, we noticed that they reached a maximum throughput that was not limited by TCP performance (this occurred with at about 7 connections in parallel on our testbed). This comes from the fact that both tools use disk access to send and receive data and thus are not only limited by general network performance, but also by other system performances. This lead us to develop a new tool we called TCPMeter for multi-flow TCP traffic generation.

(c) TCPMeter
In order to free ourselves from the possible disk speed limitations, we wrote a small tool that generates several concurrent TCP flows without using data from the disk. This tool uses boost C++ threads (Note 5), each thread managing a TCP connection. A main thread monitors the sending and receiving threads and collect statistics on each connection once they terminate. The collection of statistics is done on the receiving side and is then transmitted to the sender side for easier collection of tests results (remember the TCPDump capture are done on the sender side).
TCPMeter allows the user to specify the number of bytes to send on each connection and the number of connection to launch in parallel. The first parameters allows for varying length tests, and the second allows for testing TCP with multiple flow that compete for network resources.
TCPMeter outputs its results in an easy to read text file containing one line for each connection with its id, the port numbers used, the number of bytes sent, the times at which the connection started and finished and the measured average goodput at the Application level.
Here is an example command line used to create three TCP connections sending 100000 bytes on each connection to a host called orval: TCPMeter_V1.0 -n 3 -b 100000 -v -s orval On orval the only command necessary is: The -v option is used to generate detailed debug information on TCPMeter behaviour.

Considered TCP Flow Types and Performances Parameters
We considered in our study two kinds of flow types. First, in order to validate known results and expected advantages of PEPs, we considered basic flows obtained during the reception of a simple webpage. We then investigated the TCP behaviour and performances considering a single file transfer. Hence we make several measurement campaigns using our testbed and each time we observe the results and performances considering at least three different scenarios concerning TCP solutions: • end to end TCP NewReno connection (e2e_Nreno), • end to end TCP Cubic connection (e2e_Cubic), • split TCP connection using PEPsal with TCP Hybla on the satellite linka nd TCP Cubic on the end systems (Cubic & PEPSal).
Doing so, our objective is to consider e2e_NReno as the reference case for our measurements, the second as the typical case considering current TCP Cubic deployment, and finally the third one as an improved approach in satellite link case.
Furthermore, we extend our study considering two conditions: the case in which a single user uses exclusively its satellite Internet access for web browsing or file transfer and the case in which he shares this access with others TCP connections.
A main metric in our study is the time needed to transfer an amount of data, such as a set of contents from a web page or a single file. Generally, the transfer speed is described as the throughput which includes the original data, the protocol overheads (i.e. such as packet headers and signalisation) and packets that are retransmitted. Unlike throughtput t, goodput g only measures the transfer speed of the original data. Goodput can be calculated by dividing the size of a transmitted file by the time it takes to transfer it. It has to be noted that goodput can be considered as the application level throughput or the throughput as seen by the end user. Because our study aims at comparing performances offered to the end user by different TCP solutions, the other main metric considered as a result is the goodput in KBytes.
As our contribution not only focusses on the single user case, we also took into account other metrics. In this case of multiple TCP connection sharing a single satellite link we used the sum of the N different individual goodputs. This metric is named aggregate goodput and the TMRG (Transport Modeling Research Group) at IETF proposed in (IRTF, 2011) a formula for this metric: It must also be underlined that because packet losses are randomized and because a single experiment of a case may generate a particular set of conditions, it is necessary to play each case several time in order to ensure an accurate assessment. So, each experiment corresponding to a single scenario, for instance e2e NReno, has been played twenty times. Hence, we used those others metrics: • mean aggregate goodput, considering the set of results obtained after several experiments on one scenario, this metric represents the mean of the aggregate goodput on each experiment.
• max aggregate goodput, considering the set of results obtained after of several experiments of one scenario, this metric represents the maximum aggregate goodput that have been observed.
• mean total aggregate goodput gain (vs e2e_NReno), because e2e_Cubic and Cubic & PEPSal are expected to improve performances relatively to e2e_NReno, we measured the gain offered by each of them. Once again, considering the set of results obtained after a number experiments on one scenario, this metric represents the mean observed gain.
• mean fairness, fairness is a very important feature for any TCP variant. It refers to the capacity of a specific TCP version to ensure a fair band subdivision among competing connections that use the same version of the protocol. Jain et al. (1984) proposed a formula for this metric sometimes called the Jain's index J, that have been often used in TCP fairness assessments: Once again, considering the set of results obtained after several experiments on one scenario, this metric represents the mean fairness. It has to be underlined that in order to indicate the reliability of this result, we also give the 98% confidence interval.

Single User Web Browsing
In order to have a first feeling and to check if we observed the expected advantages of PEP, we have done a trivial measurement campaign on our testbed. This first step allows us to measure for web page load, the throughput and the total time elapsed to receive the considered webpage. The chosen webpage is quite simple with 7 objects: a main html document and six jpeg pictures (with an average picture size of 847 Kbytes). Finally, the overall webpage content shows a size of 4955 Kbytes. Using the linux wget command with adequate options in order to avoid the use of local proxy and to force the load of all files, we observe the time the web page takes to load and we deduce the obtained goodput. The linkemulator is configured in order to emulate an errored satellite link inducing a packet error rate (PER) of 1% and the typical propagation delay of 125 ms.
Of course, this experience is not strictly equivalent with the results that could be obtained using a web browser, mainly because doing so we serialize the transfer of each objects contained in the considered web page. Nevertheless, this approach has the interest to ensure that no hidden parameters or functionalities will induce on the results. And, of course, as we use the same method for each tested TCP solutions the results can be directly compared. The results are presented in Table 1. As expected, we observe that the use of PEP improves TCP performances observed at the end point with an offered goodput about four times greater than the configuration based on end to end TCP NewReno.
Nevertheless, it has also to be underlined that end to end TCP Cubic solution already allows to double the goodput comparatively to end to end TCP NewReno. As TCP Cubic is with CTCP currently widely deployed, it has from now on to be considered as a reference point to assess the gain offered by PEP approaches. Furthermore, we have to keep in mind that the entire offered capacity is in this studied case dedicated to the considered TCP connection, e.g. no exogenous TCP traffic.

Single File Transfer
As first experiment of this new part dedicated to file transfer and once again in order to verify if we obtain the expected trends, we assess end user performances obtained in case of file transfer in our main scenarios. And yet here, the linkemulator is configured on our testbed in order to emulate an errored satellite link (PER of 1%) and a propagation delay of 125ms observed in case of geostationary satellite link. The considered file have a size of 5 MBytes and its download is emulated using our home made tool TCPMeter presented in 4.2. The results are shown in Table 2. In the present experiment, the entire offered capacity is dedicated to a single TCP connection, e.g. no exogenous TCP traffic. Like in the previous section, we observe the expected trend: e2e_Cubic case improve greatly performances comparatively with e2e_NReno but the best performances are provided by the third solution which is based on PEPSal. It is important to understand that such results are due to the relative aggressiveness of the new TCP variants, particularly TCP Hybla which is used by PEPSal on the satellite hop. On a packet loss event this allows to retrieve more quickly the congestion window size reached before the loss and hence to better fill the offered capacity on the link. As we have here a single TCP connection in each experiment, the aggressiveness of the best solutions does not present drawbacks. Thanks to tcptrace, the third column of Table 2 shows the average and maximum amount of outstanding data. In our cases, e.g. in presence of high packet loss, the amount of unacknowledged outstanding data, or in flight data, is bounded by cwnd. The values obtained in e2e_Cubic case explain finally the gain observed on the goodput and file transfer time. But when PEPSal is used in order to split the end to end TCP connection, we observed nevertheless smaller values for the goodput. This is coherent with the fact that the TCP connection has been split and tcpdump command is used at the end point. We observe there the average and maximum amount of outstanding data concerning the TCP connection between the host server and the first ground station. The question we address in the next section is, what is the expected gain if the satellite link is shared by several TCP connections based on the same approach? . This new re up to 10 conne may be interp re 6 shows tha 0 in Figure 7. e more scattere