A Simulation Study of Scalable TCP and HighSpeed ... - Springer Link

Telecommunication Systems 30:4, 297–320, 2005 c 2005 Springer Science + Business Media, Inc. Manufactured in The Netherlands.

A Simulation Study of Scalable TCP and HighSpeed TCP in Geostationary Satellite Networks GIOVANNI GIAMBENE

[email protected]

Department of Information Engineering, University of Siena, Italy DANIELE MIORANDI∗

[email protected]

CREATE-NET, Via Solteri 38, 38100–Trento, Italy

Abstract. This paper investigates the performance of two TCP enhancements (i.e., Scalable TCP and HighSpeed TCP), recently proposed for high-speed backbone networks with a very large bandwidth-delay product, in a geostationary satellite environment. Both persistent and elastic traffic patterns are considered, performance being evaluated in terms of TCP throughput and mean session delay, respectively. The impact of channel characteristics (packet error rate, correlation between successive losses) is widely discussed. Fairness issues are also accounted for, together with the impact of some system parameters, such as the satellite link bandwidth. Extensive comparisons are carried out among Scalable TCP, HighSpeed TCP and other congestion control schemes. The obtained results show the soundness for the use of such protocols in geostationary satellite networks. Indeed, both protocols permit to improve the performance of TCP connections in a wide range of channel conditions, showing (especially Scalable TCP) to be able to cope well with rainy conditions and to exploit a future increase in the satellite link capacity. Keywords: satellite communications, congestion control, performance evaluation, Scalable TCP, HighSpeed TCP

1.

Introduction

Satellite communication systems represent an interesting solution to provide Internet connectivity to users located either in remote areas or in locations where fiber cabling does not represent a viable choice (e.g., high-speed trains, scarcely populated areas, the oceans, eco-tourist areas, ferry cruisers, temporary installations, civil protection intervention for disaster recovery, etc.). Clearly, these networks cannot compete, in terms of absolute performance indexes, with those based on the adoption of wired connections. On the other hand, the flexibility inherently present in satellite communications (large coverage, no need for the deployment of an infrastructure) let these solutions be of extreme interest for the next-generation Internet. The satellite will become an important part for both the core high-speed backbone and the broadband access network. In both cases, high-bit-rates are requested and the This work was carried out within the framework of the SatNex Network of Excellence, www.satnex. org ∗ Corresponding author.

298

GIAMBENE AND MIORANDI

utilization of the costly satellite link must achieve a high degree of efficiency to be profitable. Geostationary (GEO) satellite links are characterized by large propagation delays and high-bit-rate, thus yielding a large Bandwidth Delay Product (BDP) value, a characteristic in common with terrestrial high-speed backbone networks (even if in the satellite case, BDP is some orders of magnitude smaller than in high-speed backbone links). Further, satellite communications are typically affected by packet losses that have a negative impact in reducing the goodput at the Transport Control Protocol (TCP) layer [16]. Hence, it is imperative that particularly reactive protocols be employed in the satellite case to overcome the losses and to fill the pipe. Many current solutions are based on the use of split connections, where standard TCP is used on the terrestrial segment and a transport protocol tailored to satellite links is used on the satellite part. On the other hand, the introduction of novel congestion control mechanism for large BDP networks is raising the possibility of having an end-to-end solution able to perform well also in the presence of satellite links. Several TCP congestion control enhancements have been proposed to make an efficient use of bandwidth in large BDP terrestrial networks. Both theory and practice have indeed shown that the congestion control mechanism of standard TCP is unable, due to its scarce reactivity, to perform well in the presence of large BDP values. In order to overcome this problem, many efforts have been done in the past few years to design congestion control mechanisms able to operate efficiently in high BDP systems (backbone links with large amount of available bandwidth). Some examples are FAST TCP [17], XCP [19], Scalable TCP [20] and HighSpeed TCP [12]. All these protocols present a more aggressive behavior than standard TCP, in order to recover more quickly from loss events. Along slightly different lines, TCP Westwood [9] and its variant Westwood+ [15] were initially designed to shield TCP from random losses occurring on wireless links by using an estimate of the available end-to-end bandwidth. Nonetheless, their ability to deal efficiently with non-congestion losses let them outperform standard TCP in a large BDP scenario. A similar proposal is TCP Veno [13], which on one hand tries to distinguish between random and congestion losses, while, on the other one, refines the congestion window adjustment process in order to enhance the throughput with respect to standard TCP. An analogous approach characterizes the operations of TCP New Jersey [29] that bases its performance improvements on the ability to distinguish between random losses and congestion ones. It may be worth studying whether such protocols may lead to a performance improvement when applied to satellite networks that differ from the terrestrial backbone for both large Round-Trip Time (RTT) values and high transmission error rates. In particular, in this paper, we will focus our analysis on Scalable TCP (S-TCP) [20] and HighSpeed TCP (HSTCP) [12], two TCP modifications recently proposed by T. Kelly and S. Floyd, respectively. This paper represents a first attempt to understand issues related to the deployment of congestion control protocols for high-speed networks over geostationary satellite links. The choice of focusing on S-TCP and HSTCP comes from the fact that they represent major candidates for replacing the current TCP’s congestion control in the next-generation Internet. In this way, the insight gained through numerical

A SIMULATION STUDY OF SCALABLE TCP AND HIGHSPEED TCP

299

simulations may be used to study solutions able to enhance the performance of such protocols over satellite networks. Both S-TCP and HSTCP modify the congestion control algorithm of TCP in order to take advantage of the large BDP value and to overcome some shortcomings of standard TCP in these conditions. Differently from other proposed TCP modifications, both STCP and HSTCP consider only losses as a congestion signal, as in standard TCP. This approach could be thought as a “weak” point of these protocols in an error-prone scenario, since they react to random (non-congestion) losses by reducing the sending rate. On the other hand, we believe that this feature, while leading to a performance worsening with respect to other protocols reacting to delay-based congestion signalling (e.g., TCP FAST), represents a conservative choice that adds robustness to network stability. We envisage a scenario where the connection path consists of two parts. First, a high-speed link connects the server to an earth station, while a Ka-band GEO bent-pipe satellite is used to forward packets from the earth station to the final destination. We focus on two different TCP traffic patterns. • First, we refer to persistent TCP connections in order to study the ability of the congestion control mechanism to transfer extremely large amount of data at high rates and in the presence of transmission errors, as well as network congestion. We evaluate the throughput for fixed users (where the channel may be conveniently modeled as AWGN) and mobile users (where shadowing effects are accounted by means of a classical GOOD/BAD Markovian channel model [23]). In this last case, we have also considered the impact on the TCP performance due to the presence of rainy days that worsen the link budget and, consequently, increase the error rate. Fairness issues and the ability to scale with the link bandwidth are also discussed. • Then, we consider interactive data users, which browse the Web using HTTP 1.1, generating an ON/OFF elastic traffic pattern. In this case, we evaluate the mean session delay for the two aforementioned mobility scenarios. It is important to remark that we are interested in solutions able to maintain the endto-end semantics of TCP. Indeed, in the satellite communication field, much attention has been devoted to solutions splitting the connection at the earth gateway station, thus employing a dedicated transport protocol for satellite links. An example is given in [28], where XTP [27] is used as transport protocol in the satellite part. Other protocols designed to suit the features of the satellite environment are TCP Hybla [8] and TCP Peach [1] (together with its variants Peach+ and Peach++). While it is widely acknowledged that the deployment of split-based solutions may lead to a considerable performance improvement, breaking down the end-to-end semantics of TCP congestion control has a twofold drawback in terms of robustness. The first concerns the possible congestion collapse situation (especially congestion collapse from undelivered packets [10]) in the Internet, in that we might have situations where bandwidth is wasted for forwarding packets that are dropped before reaching their final destinations. The second one regards the necessity of a careful dimensioning of the buffers at the earth station, since they have to compensate for the different transmission bandwidth available on the two parts of the path (i.e., the

300


satellite part and the terrestrial one). An additional drawback of split solutions is that they inhibit the use of IPsec, representing a limitation for users interested in setting up a VPN. This paper is original since it represents the first attempt to evaluate the performance of congestion control algorithms for large BDP networks over satellite links for both fixed and mobile users. We do not just merely evaluate the performance of S-TCP and HSTCP but, running a comprehensive set of simulations (e.g., scenarios with persistent flows, short-lived flows and mixed cases, considering also rainy weather conditions etc.), we try to gain insight into the advantages and drawbacks of such protocols. In this way, we can provide guidelines that are useful for designing transport control protocols able to work well in a satellite environment. We have found that, in particular conditions, the aggressive nature of S-TCP may be harmful for short-lived connections. Further, more preliminary results show some critical aspects related to the deployment of Westwood+ on satellite links. The remainder of this paper is organized as follows: Section 2 is devoted to a description of both the protocols under study and the simulation scenario. Results are provided in Section 3, where also the comparison with the Westwood+ TCP version [15] is carried out. Finally, Section 4 concludes the paper pointing out some issues for future research. 2.

System description

2.1. TCP over satellite: A perspective TCP is deployed as layer 4 protocol in virtually all data communication networks, where reliable end-to-end data transmissions are required. Congestion and flow control are both addressed by TCP. Since its introduction, much attention has been devoted to the analysis and improvement of the congestion control algorithm of TCP that has shown to have a great impact on network performance. The congestion control mechanism of TCP has been tailored for wired networks with a not-so-large BDP and a negligible packet loss rate. Hence, the problems suffered by TCP in a satellite environment are basically of two types. The first one, common to all wireless networks, regards the impact of losses due to the radio channel, which are erroneously interpreted by TCP as due to congestion. The second one, common to all large BDP networks, is related to the inability of TCP to exploit fully the large available pipe. In this paper, we focus on solutions presented especially for the second case, and evaluate the impact on such protocols of realistic channel models for satellite systems in the presence of different TCP-based traffic flows. The congestion control algorithm of standard TCP is based upon a sliding window mechanism and consists of two phases.1 In the first one, called slow start, the sender probes the network for available bandwidth. In such phase, the congestion window (i.e., the number of packets injected into the network at each RTT) is increased by one 1

Here we refer to the TCP New Reno congestion mechanism, the standard TCP version currently deployed [3,11].


301

at the reception of each ACKnowledgment (ACK) packet, leading to an exponential throughput increase on an RTT basis. Then, after a given threshold, the sender enters the congestion avoidance phase, where it gently increases the transmission rate, according to an Additive Increase—Multiplicative Decrease (AIMD) algorithm. Congestion is detected upon loss events. A packet loss can be detected either after a timeout expiration or after the reception of three duplicate acknowledgments. In the first case, the network is assumed to be in harsh congestion and the congestion window is taken down to 1 packet. In the latter case, the congestion window is halved. Focusing on the congestion avoidance phase only, and neglecting timeout occurrences, we can then summarize the TCP behavior as: W ←− W +

1 upon an ACK arrival; W

W 2

upon a loss detection.

W ←−

S-TCP is a recent proposal for modifying the TCP congestion control algorithm in order to improve the TCP performance in backbone high-speed networks [20]. S-TCP gets its name from the fact that the time it takes to recover from a loss occurred in the presence of a congestion window value equal to W ∗ , i.e., the time it takes to return to W ∗ , does not depend on the W ∗ value. Whereas, in standard TCP, this recovery time increases linearly with W ∗ and this is one of the reasons why standard TCP behaves poorly in networks with large BDP values. S-TCP “scales” well with the congestion window value and, hence, with BDP. S-TCP is based on a Multiplicative Increase Multiplicative Decrease (MIMD) algorithm, according to which the congestion window is increased by a factor α upon an ACK reception and decreased by a factor β upon a packet loss event. The congestion window behavior can be summarized as follows: W ←− W + α upon an ACK arrival; W ←− W − βW upon a loss detection. According to Kelly [20], reasonable values are α = 0.01 and β = 0.125. We will keep these values for what follows, even if they may not be optimal for the satellite environment.2 In order to maintain fairness with existing TCP versions and to allow an incremental deployment, a legacy window of 16 packets is suggested [20]. Basically, for W ≤ 16 packets, S-TCP behaves as standard TCP. This implies that, in the presence of a small congestion window value caused by a large packet error rate, S-TCP behaves just as TCP. Further, in our implementation, S-TCP behaves as standard TCP during the slow start phase, regardless of its current congestion window value. 2

In particular, due to the not-so-large BDP value of satellite links, a larger value of α could be beneficial, leading to a faster recovery after a loss event. We leave the analysis of the impact of the α value to a future study.

302


HSTCP [12] is an adaptive window algorithm proposed for operations in networks with a very large BDP (of the order of 104 packet or more). The increment and the decrement of the congestion window, in response to an ACK reception or to a packet loss, respectively, depend on the current value of the window size, and can be represented as [12]: a(W ) W ←− W + upon an ACK arrival; W W ←− [1 − b(W )] · W upon a loss detection. Functions a(W ) and b(W ), driving the algorithm dynamics, may be expressed as functions of five system parameters, Low p, Low Window, High p, High Window and High Decrease, according to the following formulas: 2W 2 b(W ) p(W ) ; 2 − b(W ) (High Decrease − 0.5)(log W − log Low W indow) b(W ) = + 0.5; log High Window − log Low Window log Low WWindow High p p(W ) = exp + log Low p . log Low p log High Window

a(W ) =

Low Window

For evaluation purposes, we will use the following parameters [12]: Low p = 10−3 ; High p = 10−7 ; Low Window = 38 [packets]; High Window = 83000 [packets]; High Decrease = 0.1. Note that, for a congestion window value less than or equal to Low Window (which represents the legacy window threshold), the congestion control mechanism is the same as standard TCP. It is important to note that the above parameters are not suitably defined for a satellite environment.In particular, the High p value it too low and the High Window value is too large for a network with a BDP of the order of 102 packets. Note that the HSTCP performance is very sensitive to the values of these parameters (see [6] for an in-depth discussion), so that it becomes extremely difficult to make a sound comparison with other protocols. If we could know in advance the network characteristics (BDP and error rate values), then we could tune the HSTCP parameters in order to optimize its performance. However, from our point of view, the real challenge for a congestion control algorithm is to adapt to various network conditions without the need for any a priori knowledge of network features. Note that, since S-TCP and HSTCP modify the sender behavior only, they both can successfully exploit Selective ACKnowledgment (SACK) capabilities, an important aspect to be considered in the presence of correlated error events.


303

In general, both TCP enhancements behave more aggressively than standard TCP, in the sense that they let the congestion window grow faster in absence of losses, thus allowing a larger transmission rate after the detection of a packet loss. Nonetheless, they are still able to solve effectively network congestion, at least for quite large BDP values. Hence, they both entail a faster dynamics than standard TCP, whose conservative actions lead to a substantial performance degradation for high RTT values, as in the case of a GEO link. Moreover, for the parameters considered, HSTCP behaves more aggressively than S-TCP during the increase phase, but more conservatively in reaction to a loss event. In order to highlight better these factors, we have reported in figure 1 the increase in an RTT in the presence of no losses and the decrease following a loss event for the three congestion control algorithms considered (i.e., standard TCP, S-TCP and HSTCP) as a function of the congestion window size. The congestion window is taken in the interval (40, 200) packets, a range that covers most of the case studies that we will consider in what follows. As it may be seen, in this situation HSTCP is the most aggressive during the increase phase, while S-TCP gains over TCP just in the presence of a congestion window larger than 100 packets (this shows why a larger value of α is expected to be beneficial for S-TCP). On the other hand, upon a loss event, HSTCP behaves pretty conservatively, resulting in almost halving the congestion window, whereas S-TCP keeps the congestion window at a larger value. 2.2. Scenario description The scenario considered in this paper is depicted in figure 2 and has been implemented in the ns2 simulator [24]. A given number of n clients is connected, by means of a GEO bent-pipe satellite and an earth station, to a remote server in the Internet from which files are downloaded. For simulation purposes, we have assumed that the clients are located in New York and the earth station in San Francisco; the satellite is placed at 95 degrees longitude West. We study the performance (i.e., throughput) at the TCP level so that the transmitted packets are TCP segments in this study. The satellite link has a raw bandwidth of 2 Mb/s (information bit-rate at TCP level) for both uplink and downlink directions. The earth station is connected to the server through a wired link with 30 Mb/s of bandwidth and a propagation delay of 10 ms. The TCP packet is assumed to be 1 kbyte long. This leads to a BDP value of approximately 125 packets. Two traffic patterns have been considered: short-lived and long-lived connections. For the case of persistent connections, each of the n devices starts, at a time uniformly distributed between 5 and 10 seconds, the download of a file of infinite size by means of FTP. Simulations are run for 1000 seconds. In this case, the performance metric we look at is given by the aggregated throughput achieved by the n TCP connections. Moreover, we do not consider fragmentation of TCP packets. For the case of HTTP traffic (short-lived flows), each user alternates between an activity state (corresponding to the download of a Web page) and an idle one. The idle time is exponentially distributed with mean 10 seconds. Each activity period corresponds to the download of a Web page, whose size is assumed to be Pareto distributed, with

304


Congestion Window Increase in a RTT (pkts)

3

TCP S–TCP HSTCP

2.5

2

1.5

1

0.5

0 40

60

80

100

120

140

160

180

200

Congestion Window (pkts)

(a) Congestion window increase in an RTT in the absence of loss events.

Congestion Window Decrease after a Loss Event (pkts)

100 TCP S–TCP HSTCP

90

80

70

60

50

40

30

20

10

0 40

60

80

100

120

140

160

180

200

Congestion Window (pkts)

(b) Congestion window decrease after a loss event.

Figure 1. Behaviors of the TCP, S-TCP and HSTCP congestion control algorithms.

mean 30 kbytes and shape parameter β = 1.5 [18]. Note that such parameters apply to HTTP 1.1, where a single TCP connection is opened to download all the objects composing a Web page. In this case, simulations are run till each node completes the download of 300 pages. A reasonable performance metric in the presence of short-lived TCP flows is the mean session delay, defined as the mean time between the connection opening and the reception of the last packet. For users browsing the Web, indeed, the perceived satisfaction degree depends mainly on the time it takes to download a whole Web page that corresponds in our settings to the session delay.


305

Figure 2. Simulation scenario.

Each node is equipped with a buffer of 200 packets. In order to boost performance, the initial window is set to 4 TCP packets, according to [2]; this technique is known to produce a noticeable performance enhancement for short-lived HTTP-like traffic [21]. No delayed ACK option is considered. We have considered a FEC convolutional code with rate 1/2 (NASA standard with code rate 1/2 and constraint length 7; see [26] Qualcomm Viterbi decoder data) and a QPSK modulation. In the case of fixed users we assume: (i) user terminals have a Line-Of-Sight (LOS) path to the GEO satellite; (ii) a memoryless channel with uncorrelated losses and a Packet Error Rate (PER) ranging from 10−6 to 10−2 . Whereas, in the case of mobile users, a classical GOOD/BAD Markov model is considered to account for LOS and nonLOS cases, respectively [23]. In the GOOD state, we neglect packet errors after FEC decoding. In the BAD state, the non-LOS conditions (shadowing) entail a significant signal strength reduction with respect to the GOOD state so that there is a residual PER after FEC decoding (this PER value is assumed to range from 10−3 to 10−1 ). For the GOOD/BAD model we refer to [22], considering users traveling at a constant speed of 60 km/h and a 34◦ satellite elevation angle. The channel transition probability matrix can be expressed as [22]: Q=

−0.0111 1.3889

0.0111 . −1.3889

(1)

Correspondingly, the average times spent in the GOOD and BAD periods are given by TGOOD = 90 s and TBAD = 0.72 s, respectively.

306


Since we are considering a Ka-band GEO system, weather conditions have a significant impact on the link budget. In particular, rainy days can substantially reduce the ratio of the received energy per bit-to-noise spectral density, E b /N0 , thus increasing the PER values after FEC decoding. Referring to the GOOD/BAD channel, state fluctuations are due to shadowing phenomena that depend on the mobile environment, but do not depend on atmospheric events that influence only the PER values in the states. Then, in order to address the impact of rainy conditions on the system performance, we will also consider a refined GOOD/BAD model that is differentiated for two cases: clear sky days and rainy days. We have assumed the FEC decoding in [26], a QPSK modulation and that a rainy day entails a 3 dB loss in the E b /N0 value with respect to a clear sky day [4]. Moreover, we have considered that a transition from GOOD to BAD entails a loss in the E b /N0 value of 8 dB. Hence, referring to a clear sky day and LOS conditions (GOOD state), we have assumed that the link budget is dimensioned so that the E b /N0 in reception is about 9 dB; such value entails a negligible residual PER value after FEC decoding [26] for TCP segments of 1 kbyte. The transition to the BAD state entails E b /N0 = 1 dB and a corresponding PER value of about 7% [26]. Finally, for a rainy day, in the GOOD (BAD) state we consider E b /N0 = 7 dB (−1 dB) so that the PER is negligible (about equal to 1). A more refined analysis of physical layer techniques (including some form of adaptation) to counteract channel fluctuations and meteorological effects is beyond the scope of this paper and is left to a future study [7,14]. 3.

Performance evaluation

We run extensive simulations with ns2 [24], using the 2.28 version and comparing STCP and HSTCP with the two most popular versions of TCP: NewReno and SACK. Both S-TCP and HSTCP have been implemented over SACK. The code for HSTCP is present in the ns2 distribution, whereas the S-TCP code has been added by the authors. 3.1. Persistent TCP connections We first addressed performance issues in the presence of persistent TCP connections, and evaluated the average throughput experienced by different fixed users in various channel conditions (for the memoryless channel case). The performance results of the four different TCP versions considered, in terms of throughput versus PER in a static environment, are shown in figure 3. As it may be seen, all the protocols behaves similarly at very low PER values; however as PER reaches 10−4 , S-TCP and HSTCP overcome the performance of NewReno and SACK, due to their inherent ability to recover faster from a loss event. At a PER rate of 10−3 , the HSTCP dynamics reduces basically to standard TCP, while S-TCP is able to attain a valuable performance improvement over the other protocols, due mainly to its more aggressive behavior during the decrease phase. In the presence of large PER values (of the order of 10−2 or even larger), all the considered


307

6

2

x 10

1.8

1.6

TCP Throughput (bit/s)

1.4

1.2

1

NewReno SACK S–TCP HSTCP

0.8

0.6

0.4

0.2

0 –6 10

–5

–4

10

10

–3

10

–2

10

Packet Error Rate

Figure 3. TCP throughput for a single connection in a fixed user scenario (memoryless channel).

protocols achieve similar performance. These results can be predicted by considering the response functions of the congestion control algorithms under study. Taking a BDP of 125 (our network scenario), standard TCP is able to exploit fully the available bandwidth for a PER value less than or equal to PER∗ = B 1.5 ≈ 10−4 [10]. On the other hand, for D P2 √

HSTCP this value is equal to PER∗ = ( B D1.5P )1.2 ≈ 3.9 · 10−3 [12]. Finally the response function of S-TCP leads to PER∗ ≈ 0.094 ≈ 7.5 · 10−4 [20]. However, it may be seen in BDP figure 3 that for a PER value slightly exceeding this threshold, the performance of S-TCP decreases more gently than both HSTCP and standard TCP. The similar performance of NewReno and SACK are explained by the low probability of multiple losses within the same window of data. Similar results may be obtained in the presence of multiple competing connections, as reported in figure 4 for the memoryless channel case with PER = 10−3 . In this case, indeed, S-TCP is able to attain a remarkable performance enhancement for a low number of TCP connections. However, as soon as the number of connections increases, the congestion window value of each individual connection lowers down, so that all the protocols achieve similar performance. The situation changes when we consider mobile users. In the mobile scenario described in the previous Section, the large ratio of TGOOD over TBAD leads to a situation where the average congestion window is pretty large. With low PER values, the channel is expected to approach the behavior of an AWGN channel. On the other hand, in the presence of large PER values, the probability of multiple losses within the same window of data is non-negligible. In such case, the use of selective acknowledgments becomes

308

GIAMBENE AND MIORANDI 6

1.88

x 10

1.86

Aggregated TCP Throughput (bit/s)

1.84

1.82


1.8

1.78

1.76

1.74

1.72

1.7

1.68

3

4

5

6

7

8

9

10

11

Number of TCP connections

Figure 4. Aggregated TCP throughput versus number of concurrent persistent TCP connections in a static scenario (memoryless channel), PER= 10−3 .

an important feature, leading to a significant performance improvement for SACK with respect to NewReno. This is due to the fact that NewReno recovers from losses at a rate of one packet per RTT, thus causing a significant performance penalty in the presence of large RTT values, as in the geostationary satellite case. The results, in terms of throughput versus PER in the BAD state, are reported in figure 5 for the single-connection case. We can also notice that SACK, S-TCP and HSTCP all show similar performance. In this scenario, indeed, the driving factor turns out to be not the capacity to recover quickly from losses but, rather, the ability of using SACK information. Results drastically change when we refer to a urban environment, where from Lutz et al. [22] we get TGOOD = 2.16 s and TBAD = 2.97 s for a mobile speed of 40 km/h. In such a case, during a sojourn in the BAD state it is highly likely that a TCP timeout occurs, taking down the congestion window to one packet. Further, since the GOOD state duration is short, it is highly unlikely that the congestion window will grow over few packets. Hence, the congestion window is expected to oscillate around small values. Simulation outcomes are shown in figure 6, where it may be seen that S-TCP slightly outperforms the other congestion control mechanisms. It is important to remark that the driving parameter in the dynamics of TCP over a long-delay two-state Markov channel is the time spent in the BAD state. If the mean sojourn time in the BAD state is long, many loss events are detected by timeout expirations, thus causing a significant throughput reduction. In this case, the considered protocols would have similar performance (apart from the cases of extremely small


309

6

1.9

x 10

1.85


1.8


1.75

1.7

1.65

1.6

1.55

1.5 –3 10

–2

–1

10

10

Packet Error Rate in the BAD State

Figure 5. TCP throughput in a mobile scenario versus frame error rate in the BAD state. 5

18

x 10

16 NewReno SACK S–TCP HSTCP


14

12

10

8

6

4

2

0 –3 10

–2

10

–1

10

Packet Error Rate in the BAD State

Figure 6. TCP throughput in a mobile scenario versus frame error rate in the BAD state, urban environment, user speed 40 km/h.

average congestion windows, where S-TCP performs worse than the others). On the other hand, with a short BAD period, the key factor is the ability to recover fast from multiple losses within the same window of data. In this case, SACK-enabled protocols achieve higher performance than NewReno, since the latter recovers from losses at a rate of one packet per RTT, thus suffering from the long delays introduced by the satellite

310


1.9

x 10

1.8


1.7

1.6

1.5 NewReno SACK S–TCP HSTCP

1.4

1.3

1.2

1.1

1 20

30

40

50

60

70

80

90

100

Mobile Speed (km/h)

Figure 7. TCP throughput in a mobile scenario versus mobile user speed, frame error rate in the BAD state 10−1 (highway environment).

link. Further, if PER in the BAD state is small, the loss process will approach the memoryless case, leading to the considerations already done for the case of fixed users in terms of protocols performance. In order to analyze better these factors and to study the applicability of the proposed algorithms to high-speed scenarios, we run simulations changing the mobile user speed. Assuming the highway model in Lutz et al. [22], we have that the mean GOOD and BAD state durations can be expressed, as functions of the mobile speed v (in km/h) as: TGOOD =

5400 [s], v

TBAD =

43.2 [s]. v

We considered mobile speeds ranging from 20 to 100 km/h, with 20 km/h steps. The results are plotted in figure 7 for a PER in the BAD state of 10−1 . As it may be seen, NewReno is unable to cope with fast channel dynamics, due to the slow recovery from multiple losses. Moreover, the other three algorithms perform similarly, with S-TCP and HSTCP slightly overcoming SACK for high speed values. 3.2. Short-lived TCP flows We now turn our attention to the case of interactive users, which browse the Web through a satellite connection. We fix the number n of clients and run simulations for various PER values. The results for an AWGN channel are reported in figure 8 in terms of mean session delay. As it may be seen, performance gently decreases with PER till 10−2 . The performances of the various protocols do not show differences that are worth


311

8

Mean Session Delay (s)

7


6

5

4

3

2 –5 10

–4

10

–3

10

–2

10

–1

10

Packet Error Rate

Figure 8. Mean session delay in a static scenario versus frame error rate for n = 10 users.

of comments, since most transfers end in the slow start phase, where all the protocols behave in the same way. We have also considered the performance of interactive users in a mobile environment, where the channel has the transition rate matrix described in (1). The performance obtained, expressed in terms of mean session delay versus PER in the BAD state, is shown in figure 9. As it may be seen, for the whole range of PERs considered, all the protocols achieve similar performance. This is due to the fact that connections are expected to be extremely short, so that they rarely exceed the legacy window. Accordingly, also the probability of multiple losses within the same window of data is very low. For the traffic pattern considered for Web browsing applications, most of the sessions end while TCP is still in the slow start phase. In a geostationary satellite environment, the slow start phase is known to be inefficient, due to the long link delay, which in turn leads to a slow opening of the congestion window. Such problem may be only partially solved by the adoption of the increased initial window option [2]. In this sense, one interesting issue for further investigations is the study of the impact of mechanisms aiming at speeding up the window increase at the beginning of a connection, as for example TCP FastStart [25]. However, these techniques would probably require explicit feedbacks from routers in order to preserve network stability. 3.3. Related issues One important aspect, when dealing with TCP enhancements, is fairness. We heuristically define a TCP modification to be fair if it provides a fair sharing of the available bandwidth with standard TCP connections. The risk is that an aggressive

312

GIAMBENE AND MIORANDI 2.55

Mean Session Delay (s)

2.5


2.45

2.4

2.35

2.3

2.25 –3 10

–2

10

–1

10

Packet Error Rate in the BAD state

Figure 9. Mean session delay in a mobile scenario versus frame error rate in the BAD state for n = 10 users.

TCP modification gets all the bandwidth, causing starvation problems for those connections that use standard TCP. Fairness is a necessary requirement in order to allow incremental deployment, without which the proposed modifications cannot be practically implemented. It is worth noting that fairness problems arise only in presence of persistent TCP connection, whereas in the presence of interactive users fairness does not really represent such an important issue. In order to analyze the fairness issue, we have considered an “enhanced” TCP connection, i.e., one utilizing either S-TCP or HSTCP, and a competing standard SACK connection. We run simulations for both static and mobile users, varying the PER, as done in the previous subsections. Some plots are shown in figure 10, while the average obtained throughput values are shown in Table 1. We can summarize the results as follows: • In an AWGN channel, S-TCP and HSTCP do not grab the whole channel. In particular, HSTCP behaves similarly to standard TCP, leading to a fair share of the bandwidth. On the other hand, S-TCP, due to its more aggressive behavior, is able to outperform SACK. One interesting observation is that, in any case, the throughput of the SACK connection does not differ much in the two cases. This means that S-TCP is able to utilize a bandwidth, which would otherwise be doomed to be wasted in the presence of another SACK or HSTCP connection. • Things become much worse in the presence of a Markovian channel, where, as it may be seen from the graphs, both S-TCP and HSTCP tend to utilize most of the bandwidth, lowering the performance figures for the SACK connection. In this case,


6

6

x 10

2

1.8

1.8

1.6

1.6

1.4

1.4



2

1.2

1

0.8

0.6

x 10

1.2 SACK S–TCP Aggregated

1

0.8

0.6

0.4

0.4 SACK S–TCP Aggregated

0.2

0

313

0

100

200

300

400

500

600

0.2

700

800

900

0

1000

0

100

200

300

400

Time (s)

500

600

700

800

900

1000

Time (s)

(a) AWGN channel, PER=0.001, SACK and S-TCP.

(b) GOOD/BAD channel, PER=0.1 in the BAD state, SACK and S-TCP.

6

6

x 10

2

1.8

1.8

1.6

1.6

1.4

1.4



2

1.2

1

0.8

0.6

1.2 SACK HSTCP Aggregated

1

0.8

0.6

0.4

0.4 SACK HSTCP Aggregated

0.2

0

x 10

0

100

200

300

400

500

600

700

0.2

800

900

0

1000

0

100

200

300

400

Time (s)

(c) AWGN channel, PER=0.001, SACK and HSTCP.

2

1.8

1.6

1.6

1.4

1.4



700

800

900

1000

6

x 10

1.8

1.2

1

0.8

0.6

x 10

1.2

S–TCP HSTCP Aggregated

1

0.8

0.6

0.4

0.4 S–TCP HSTCP Aggregated

0.2

0

600

(d) GOOD/BAD channel, PER=0.1 in the BAD state, SACK and HSTCP.

6

2

500

Time (s)

0

100

200

300

400

500

600

700

800

0.2

900

1000

0

0

100

200

Time (s)

300

400

500

600

700

800

900

1000

Time (s)

(e) AWGN channel, PER=0.001, S-TCP and HSTCP. (f) GOOD/BAD channel, PER=0.1 in the BAD state, STCP and HSTCP.

Figure 10. Fairness issues for two competing persistent TCP connections.

314


Table 1 Mean throughput values for two competing persistent connections, 95% confidence interval. SACK −3

Throughput (bit/s), AWGN, PER = 10 Throughput (bit/s), G/B, PER = 10−1

Throughput (bit/s), AWGN, PER = 10−3 Throughput (bit/s), G/B, PER = 10−1

−3

Throughput (bit/s), AWGN, PER = 10 Throughput (bit/s), G/B, PER = 10−1

S-TCP

[537565, 566419] [198705, 223439]

[1115967, 1149393] [1633842, 1669102]

SACK

HSTCP

[556305, 592383] [413170, 432990]

[662971, 705765] [1426120, 1453720]

S-TCP

HSTCP

[856022, 892602] [1315728, 1360928]

[844916, 880316] [507172, 548972]

due to the short duration of the BAD state, both S-TCP and HSTCP are able to exploit fully the bandwidth. As it may be seen from the graphs, most losses are synchronized (i.e., both connections suffer from losses at the same instant) and in this case the more aggressive behavior of the proposed TCP modifications enable them to get a larger throughput than standard TCP. Note that synchronized losses are only due to congestion, since the two satellite-to-client links experience independent shadowing. On the other hand, the non-negligible amount of non-synchronized losses present in the AWGN channel enhances the fairness between the two connections. A detailed analysis of this problem and related ones can be found in Altman et al. [5]. From the results therein it turns out that, in order to achieve a fair share of the bandwidth with S-TCP, the user with SACK should open 3 parallel connections. Similar conclusions may be drawn also for HSTCP. We tested also the performance in the presence of one S-TCP connection and an HSTCP one. As it may be seen from the graphs in figure 10, in AWGN channels the two protocols get a fair share of the bandwidth, whereas this does not hold any longer in the two-state Markov channel we considered. In this case, most losses are synchronized, so that if initially the aggressiveness of HSTCP in the increase phase let it take some more bandwidth, its more conservative behavior in reaction to losses let finally S-TCP get most of the bandwidth. Westwood+ [15] is an interesting modification of the TCP congestion control mechanism, based on an Additive Increase Adaptive Decrease (AIAD) mechanism. Westwood+ continuously maintains an estimate of the available end-to-end bandwidth along the connection path, based upon a low-pass filtering of the ACK flow. TCP Westwood+ has been originally designed for wireless networks, and, to the best of the authors’ knowledge, no in-depth evaluation of its performance over paths comprising a satellite link has been carried out. Westwood+ can be considered the actual state-ofthe-art in congestion control over lossy links, so that through its study we may gain insight into the shortcomings of wireless-based solutions when applied to our satellite


315

scenario. We have been running some sets of simulations in order to understand possible drawbacks related to its deployment. From our preliminary results, it turns out that Westwood+ is able to attain excellent performance figures in most simulation settings we considered in the paper. Nonetheless, there are two factors that need to be accounted for when dealing with Westwood+ over satellite networks. The first one is related to the low-pass filter used for bandwidth estimation. As it may be readily understood, such filter has a great impact on the protocol performance. In particular, one concern that arises is that the estimate is updated once per RTT. In the presence of very large delays, as it happens in GEO satellite networks, the effect is that the protocol reacts slowly to changes in the available bandwidth. As it can be understood, this may be harmful in the presence of a GOOD/BAD channel. For instance, we considered a channel with average duration of the GOOD and BAD states equal to TGOOD = 6 s and TBAD = 2 s. In general, this would be considered a slowly-varying channel. However, on a RTT timescale the fluctuation is pretty fast, and, as a consequence, the low-pass filter of Westwood+ is unable to deal efficiently with it; in particular, we got a throughput, for a single connection, of 133.3 kbit/s for NewReno, 143.9 kbit/s for SACK, 203.8 kbit/s for S-TCP, 131.3 kbit/s for HSTCP and 176.6 kbit/s for Westwood+. These results suggest that a tuning of Westwood+ design parameters may be necessary to successfully deploy it over satellite links. Another critical aspect we found is related to the ability of Westwood+ to perform well in large BDP links with small buffer capacities. One interesting issue in deploying enhanced congestion control protocols is indeed their ability to take advantage of a future increase in the bandwidth of satellite links. While for the time being the transmission rate of 2 Mbit/s we considered is a possible value for S-UMTS and DVB-S scenarios, it may be foreseen, in the medium term, that such link capacity could increase up to an order of magnitude. We thus tested the scalability of the five protocols considered (including Westwood+) with respect to the link bandwidth. We have employed 10 persistent TCP connections, and evaluated the efficiency, defined as the ratio between the aggregated TCP throughput and the link capacity. The results are reported in figure 11, where the efficiency is plotted versus PER for an AWGN channel. As it may be seen, S-TCP is effectively able to exploit such an increase in the link bandwidth, getting an almost constant link utilization without requiring larger buffers. On the other hand, standard TCP (both SACK and NewReno) is unable to exploit fully the larger available bandwidth. An intermediate performance figure is obtained by HSTCP, which outperforms standard TCP, but it is unable to track closely the available bandwidth. These results do not differ so much from those obtained for mobile users in figure 12. In this case, however, the SACK ability to recover fast from losses plays an important role, so that the performance obtained by SACK is much better than that obtained by NewReno. Further, HSTCP performance turns out to be similar to the SACK one, while S-TCP can outperform all the other protocols also in this scenario by exploiting better the available bandwidth. From figures 11 and 12, it may be seen that Westwood+ is unable, in both scenarios, to take full advantage of the available bandwidth. This is more visible in the GOOD/BAD case where, again, the pipe is almost always filled, and most packet drops are due to buffer

316


0.95

0.9

Efficiency

0.85 NewReno SACK S–TCP HSTCP Westwood+

0.8

0.75

0.7

0.65

0.6

2

3

4

5

6

7

8

9

10

Satellite Link Capacity (Mb/s)

Figure 11. Efficiency versus satellite link capacity, AWGN channel, PER=10−3 , n = 10 persistent connections. 0.95

0.9

Efficiency

0.85 NewReno SACK S–TCP HSTCP Westwood+

0.8

0.75

0.7

2

3

4

5

6

7

8

9

10

Satellite Link Capacity (Mb/s)

Figure 12. Efficiency versus satellite link capacity, two-state Markovian channel, PER= 0.1 in the BAD state, n = 10 persistent connections.

overflow. This problem requires a careful tuning of the Westwood+ design parameters, since it may represent a limiting factor in its deployment over networks with large BDP and small buffers. We are also interested in studying the ability of these protocols to support simultaneously long-lived and short-lived connections. The motivations come from the


317

Table 2 Performance in presence of 10 interactive data users and one persistent TCP connection (AWGN channel, PER = 10−3 ).

NewReno SACK S-TCP HSTCP

Mean session delay (s)

TCP throughput (bit/s)

2.3348 2.3031 2.3152 2.3146

746440 744768 1042028 779168

increasing popularity of peer-to-peer applications for the exchange of multimedia (audio and video) contents. Such applications, indeed, are playing an important role as sources of Internet traffic, and are characterized by transfers of extremely long files, in the order of 107 –109 bits. The congestion mechanism of TCP tends to provide age-based priority, thus giving higher throughput to “old” connections than to the “new” ones. Together with drop-tail policies for router buffers, the overall effect is to penalize short flows with respect to long ones. This behavior may be extremely harmful in a scenario where Web browsing coexist with some peer-to-peer applications, since the latter may get all the bandwidth, causing starvation problems to the interactive Web users. The general trend of TCP modifications for large BDP networks is to exacerbate such problems, providing higher throughput in the congestion avoidance phase. In order to check the ability of the proposed TCP modifications to deal with such issues, we have considered a mixed scenario, where both persistent and short-lived connections coexist and share the available bandwidth. In particular, we considered one persistent TCP connection, and 10 interactive users, which are generating a Web browsing traffic pattern, according to the parameters described in Section 2.2. We considered a static scenario, and run simulations for 1000 seconds. The results, in terms of mean session delay for interactive users and throughput for persistent connections are reported in Table 2. It is worth remarking that the main performance index in such setting is the one concerning interactive users, since, for peer-to-peer users, a difference in throughput of even 20% would probably not lead to a too different perception of network performance. From the results shown in the table, we can remark that no noticeable difference arises among the various protocols in terms of the mean session delay for interactive data users. On the other hand, the throughput obtained by the S-TCP connection is much higher than that achieved by the other protocols considered. Even in this scenario, S-TCP provides interesting performance, being able to guarantee higher throughput to persistent flows without reducing the performance of users browsing the Web. Results drastically change when we focus on a mobile scenario with a PER in the BAD state of 10−1 . In this case, indeed, the pipe is almost always filled, a harmful scenario for short-lived TCP flows, that encounter difficulties in gaining bandwidth. Simulation results are reported in Table 3. As it may be seen, NewReno and SACK are able to offer an interesting performance compromise for both long-lived and elastic

318


Table 3 Performance in presence of 10 interactive data users and one persistent TCP connection (GOOD/BAD channel), PER in the BAD state 10−1 ).

NewReno SACK S-TCP HSTCP

Mean session delay (s)

TCP throughput (bit/s)

2.8521 3.5166 7.1475 5.0202

1538204 1861220 1873162 1885892

Table 4 Average throughput of one persistent connection in clear sky and rainy conditions. Throughput in clear sky conditions (bit/s)

Throughput in rainy conditions (bit/s)

1532720 1860328 1865624 1865224

1062160 1487256 1813672 1661136


traffic patterns. On the other hand, the more aggressive behavior of S-TCP and HSTCP has the negative effect of favoring persistent connections, arising starvation problems for Web users. This leads to the necessity of studying mechanisms for protecting shortlived flows against this type of unfairness, an issue that has not been dealt with in the literature. Finally, we studied also the performance of the considered protocols in a rainy environment. We simulated a single persistent connection, and evaluated the throughput for clear sky and rainy conditions, according to the link budget described in Section 2. The results are shown in Table 4. As it may be seen, standard TCP shows a non-negligible performance worsening in the presence of rainy conditions. On the other hand, HSTCP and S-TCP are able to attain remarkable performance improvements over both NewReno and SACK, S-TCP showing only a marginal performance degradation with respect to clear sky conditions. 4.

Conclusions

In this paper we have analyzed the performance of some TCP enhancements, namely Scalable TCP (S-TCP) and HighSpeed TCP (HSTCP), in a geostationary satellite network. We have considered both fixed and mobile users under two different traffic patterns, respectively for long-lived TCP flows and interactive users that browse the Web via HTTP applications. The results, obtained by means of ns2 simulations, have highlighted that these protocols may represent a viable choice for accessing the Internet via satellite links.


319

They are indeed able to outperform standard TCP in a wide range of scenarios in terms of throughput for persistent TCP connections, while presenting similar performance results for interactive data users. Moreover, their faster dynamics allow them to track channel variations for users moving at very high speed, without incurring in penalties in the presence of a slowly varying channel. Both have shown to be able to perform well in the presence of rainy conditions. Finally, S-TCP is able to exploit better than standard TCP any future increase in the satellite link bandwidth, showing better scaling with respect to the BDP value. Two topics represent directions of particular interest for future research. The first one concerns the study and the optimization of S-TCP and HSTCP parameters for satellite environments. The second one is represented by the study of the interactions of data link layer techniques (e.g., FEC and resource management schemes) with such protocols. Acknowledgments The authors want to thank N. Celandroni (CNR-ISTI), B. J. Prabhu and A. A. Kherani (INRIA) for the useful discussions on the subject. References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14]

I.F. Akyildiz, G. Morabito and S. Palazzo, TCP-Peach: A new congestion control scheme for satellite IP networks, IEEE/ACM Trans. on Netw. 9(3) (2001) 307–321. M. Allman, S. Floyd and C. Partridge, Increasing TCP’s initial window, RFC 2414, (1998). M. Allman, V. Paxson and W. Stevens, TCP congestion control, RFC 2581 (1999). M.-S. Alouini, S.A. Borgsmiller and P. G. Steffes, Channel characterization and modeling for Ka-band very small aperture terminals, IEEE Proceeding 85(6) (1997) 981–997. E. Altman, K. Avrachenkov and B.J. Prabhu, Fairness in MIMD congestion control algorithms, In Proc. of IEEE INFOCOM Miami, (2005). E. Altman, K.E. Avratchenkov, A.A. Kherani and B.J. Prabhu, Performance analysis and stochastic stability of congestion control protocols, in Proc. of IEEE INFOCOM, Miami, (2005). C. Barakat and E. Altman, Bandwidth tradeoff between TCP and link-level FEC, Computer Networks 39(2) (2002) 133–150. C. Caini and R. Firrincieli, TCP Hybla: A TCP enhancement for heterogeneous networks, Int. J. Sat. Comm. and Netw. 22 (2004) 547–566. C. Casetti, M. Gerla, S. Mascolo, M.Y. Sanadidi and R. Wang, TCP Westwood: Bandwidth estimation for enhanced transport over wireless links, in Proc. of ACM Mobicom (Rome, Italy, 2001). S. Floyd and K. Fall, Promoting the use of end-to-end congestion control in the Internet, IEEE/ACM Trans. on Netw. 7 (1999) 458–472. S. Floyd and T. Henderson, The NewReno modification to TCP’s fast recovery algorithm. RFC, 2582, (1999). S. Floyd, HighSpeed TCP for large congestion windows, RFC 3649, Dec. 2003. C.P. Fu and S.C. Liew, TCP Veno: TCP enhancement for transmission over wireless access networks, IEEE J. Sel. Ar. Comm. 21(2) (2003). G. Giambene and M. Marandola, Internet access in hybrid terrestrial and satellite mobile communication systems, in: Proc. of IEEE VTC Spring (Milano, IT, 2004).

320


[15] L.A. Grieco and S. Mascolo, Performance evaluation and comparison of Westwood+, New Reno, and Vegas TCP congestion control, ACM Computing Communication Review 34(2) (2004) 25–38. [16] V. Jacobson and M.J. Karels, Congestion avoidance and control, in; Proc. of ACM SIGCOMM, Stanford, CA, 1988. [17] C. Jin, D. Wei and S. Low, FAST TCP: Motivation, architecture, algorithms and performance, in: Proc. of IEEE INFOCOM (San Francisco, CA, 2003). [18] Y. Joo, V. Ribeiro, A. Feldmann, A.C. Gilbert and W. Willinger, TCP/IP traffic dynamics and network performance: A lesson in workload modeling, flow control and trace–driven simulations, ACM Computer Communications Review 31 (2001) 25–37. [19] D. Katabi, M. Handley and C. Rohrs, Congestion control for high bandwidth-delay product networks, in: Proc. of ACM SIGCOMM (Pittsburgh, 2002). [20] T. Kelly, Scalable TCP: improving performance in highspeed wide area networks., ACM Computer Communication Review 32(2) (2003). [21] H. Kruse, M. Allman, J. Grinera and D. Tran, Experimentation and modeling of HTTP over satellite channels, Int. J. of Sat. Comm. 19(1) (2001). [22] E. Lutz, D. Cygan, M. Dippold, F. Dolainsky and W. Papke, The land mobile satellite communication channel—recording, statistics and channel model, IEEE Trans. on Veh. Techn. 40(2) (1991) 375–386. [23] E. Lutz, M. Werner, and A. Jahn, Satellite Systems for Personal and Broadband Communications Springer–Verlag, Berlin, DE, 2000. [24] The network simulator ns2, 2005. ver. 2.28. [25] V.N. Padmanabhan and R.H. Katz, TCP fast start: a technique for speeding up Web transfers, in Proc. of Globecom (Sidney, 1998). [26] Qualcomm. Q1401: K = 7 rate 1/2 single-chip Viterbi decoder technical data sheet 1987. [27] R.M. Sanders and A.C. Weaver, The Xpress Transfer Protocol (XTP)—a tutorial, ACM Computing Communiaction Review 20 (1990). [28] SkyX technology white paper, 2002. [29] K. Xu, Y. Tian and N. Ansari, Improving TCP performance in integrated wireless communications networks, Computing Network 47(2) (2005) 219–237.