DYNAMIC CONGESTION CONTROL FOR SATELLITE NETWORKS ...

DYNAMIC CONGESTION CONTROL FOR SATELLITE NETWORKS EMPLOYING TCP PERFORMANCE ENHANCEMENT PROXIES Lijuan Wu, Fei Peng and Victor C. M. Leung Department of Electrical and Computer Engineering, The University of British Columbia Vancouver, BC, Canada V6T 1Z4 {lijuanw, feip, vleung}@ece.ubc.ca Abstract - Transmission Control Protocol (TCP) is widely used for reliable data transfer over the Internet. TCP suffers significant performance degradations over satellite networks due to high latency and bit-error rate (BER) of satellite links. Use of performance enhancement proxies between split TCP connections over the satellite and terrestrial Internet segments have been proven attractive to improve TCP performance while keeping the TCP configurations in end systems unchanged. In this paper, we propose a dynamic congestion control mechanism called dynamic Vegas (DVegas), for the satellite segment in a split TCP connection scenario. This scheme uncouples the TCP flow control and error recovery operations and allows immediate congestion feedback from underlying layers. We model a network of very small aperture terminals accessing a common satellite uplink using a medium access control protocol. Simulation results show that our proposed mechanism improves TCP performance significantly and is more robust when the traffic load is heavy. I.

INTRODUCTION

Satellite provides an attractive means to offer high-speed Internet access to remote users and efficient data delivery to geographically dispersed subscribers. Satellite channels are characterized by long propagation delays, large band-widthdelay products and relatively high bit-error rates (BERs). For example, end-to-end delay for geo-synchronous earth orbit (GEO) systems can range from 240 to 280 ms. This long delay causes a large bandwidth-delay product, which means that a large number of packets must be kept “in flight” to fully utilize the satellite link. Packet corruption is another concern in satellite transmissions. Uncoded satellite channels can have BER values around 10-6. The Transmission Control protocol (TCP) is a transport protocol used by many Internet applications for end-to-end reliable data delivery. While TCP performs well in terrestrial networks, the inherent characteristics of satellite links often result in significant degradation of TCP throughput. The first concern is the relatively higher BERs over satellite links. TCP treats all packet losses as network This work was supported by grants from Com Dev International, the Canadian Institute for Telecommunications Research under the NCE program of the Canadian Government, and by the Canadian NSERC/CSA Partnership Program under grant CSA223232-98.

0-7803-8523-3/04/$20.00 ©2004 IEEE.

congestion, which is the case in terrestrial networks, and cuts its congestion window accordingly. This may not be an appropriate response for satellite networks as packet losses may be caused by transmission errors over the satellite links. The second problem is that TCP slow-start will take up to several seconds to enter congestion avoidance due to the long round trip time (RTT) over satellite, so that short-lived connections suffer from low throughput. The third problem is that the offered window size field in the TCP header is only 16-bit long, which restricts the window size to 64K. This problem can be overcome by using the TCP window scaling option. A lot of research has been done to improve TCP performance over satellite networks. The possible solutions can be classified as: link layer solutions, end-to-end solutions, and performance enhancement proxy (PEP) [1] solutions. Link layer solutions employ retransmissions and forward error correction to mitigate packet losses over satellite links due to transmission errors. However, these methods cannot overcome TCP performance degradations over satellite links caused by latency. Most end-to-end solutions appear as extensions or options to current TCP versions. The effectiveness of these solutions is limited by the fact that not all end systems support such extensions. The PEP approach employing split TCP connections is attracting much attention nowadays as an effective solution for satellite networks. The advantage of a split-connection PEP is that it acts on behalf of end systems without changing their TCP configurations. The proxy services are customized to compensate for specific link characteristics that would otherwise cause poor performance. Both the link layer solution and end-to-end solution can be combined with this method to enhance TCP performance. In earlier work, a number of protocols have been adapted to satellite links to provide proxy services between PEPs. Proposals like [2] and [3] use extensions of TCP Reno to enhance performance. Proposal [4] introduced a protocol based on TCP Vegas to accelerate throughput. These mechanisms are based on current TCP versions and thus unable to distinguish between packet losses due to congestions or transmission errors. Another well-known proposal is the satellite transport protocol (STP) [5], which employs a propriety protocol stack over the satellite link. However, this approach is complicated and potentially costly to implement. These methods have been considered

for system architectures using either dedicated satellite channels or terrestrial links on the reverse path. In this paper, we propose a dynamic congestion control mechanism for TCP Vegas (DVegas) implemented as a proxy service over a satellite network employing splitconnection PEPs. The aim is to uncouple the TCP flow control and error recovery mechanisms over the satellite link. To combat the shortcoming of long propagation delay, our mechanism uses cross-layer feedback at the PEP. We investigate and compare the performance of our new method with different TCP versions over different traffic load. The investigation employs a simulation model in which a large number of very small aperture terminals (VSATs) share an uplink satellite channel using an appropriate medium access control (MAC) protocol. The rest of this paper is organized as follows. Section II introduces the system architecture and configuration. Section III reviews different TCP versions and describes our dynamic congestion control mechanism. Section IV discusses the simulation results. Section V concludes the paper. II.

SYSTEM ARCHITECTURE

A. Split-Connection Performance Enhancement Proxy The split TCP connection approach employs a PEP to partition an end-to-end TCP connection into satellite and terrestrial segments. The idea behind split connections is to isolate the long propagation delay and lossy links from other well-behaved parts of the network, in a way transparent to end hosts. The terrestrial segment would employ the standard TCP protocol to guarantee compatibility with all Internet hosts. Protocol stacks used between proxies may be customized to match the characteristics of satellite links. Availability of low cost VSAT return links makes it practical to consider in this paper a model in which the satellite reverse link is shared by a number of VSATs. Fig. 1 illustrates the system architecture for Internet access via satellite. A number of VSATs are located at the subscriber premises, which enable end hosts to access the Internet via satellite. The VSATs employ a MAC protocol to access and share the satellite uplink bandwidth. In the split TCP configuration, one PEP sits at the gateway connecting the satellite network to local web servers or the global Internet,

Fig. 1 System Architecture

while the other PEP is located at a VSAT. When an end host wants to set up a TCP connection, the gateway will intercept this request and set up a cascading TCP connection for it. The gateway is granted fixed bandwidth over a dedicated satellite channel. The PEPs are responsible for local acknowledgments and retransmissions over the satellite network. B. Random Early Mark (REM) Queue One of the novelty of our approach is that we deploy a random early mark (REM) queue [6] for active queue managment (AQM) at the MAC layer of each earth station where a PEPs is collocated. The REM queue algorithm is employed to detect incipient congestion of the satellite network, but the information is used in the TCP layer to control the sending window size. The most important parameters that characterize a REM queue are the thresholds minthresh and maxthresh, used to determine different phases of congestion and to switch between different AQM algorithms. The REM queue also maintains an estimate of the average queue length, qavg. In a regular REM queue, when minthresh < qavg < maxthresh, the system randomly marks the incoming packets with certain probability (we use a linear function that increases from 0 to 10%). It begins to randomly drop the incoming packets with increasing probability when qavg > maxthresh (we use a linear function that increases from 10% to 100% when qavg increases from maxthresh to 2maxthresh). Normally the REM queue must be used together with TCP senders and receivers capable of Explicit Congestion Notification (ECN) [7]. Currently, this is the only practical method to identify the reason, either congestion or transmission error, that a packet is lost. However, it will take one RTT for the sender to react, which is harmful to TCP performance because the RTT over satellite is as much as 550 ms. Fortunately, in a satellite network the uplink is always the bottleneck. It is therefore possible to directly feedback congestion information from the MAC layer to the TCP sender at the PEP. This is a novel feature of the proposed method. C. MAC Protocol The Combined Free/Demand Assignment Multiple Access (CFDAMA) [8] is selected as the MAC protocol for the common uplink shared by the VSATs. It combines free assignment of data slots as well as demand assignment, which can achieve low access delay when traffic load is light and efficient statistical multiplexing over the shared satellite channel when traffic load is heavy. The frame structure for the shared uplink (VSAT to gateway) is illustrated in the Fig. 2. The uplink frame consists of the reservation slot followed by a number of data slots. The reservation slot is subdivided into several mini-slots. Each VSAT owns one mini-slot in which it transmits its reservation request if it has packets accumulated in its buffer.

C. TCP Vegas

Reservation R

DATA

R

Minislot

DATA

Data Slot F/D

...

F/D

F/D

......

TCP Vegas controls the congestion window by observing changes in RTTs of segments that have been sent. In the congestion avoidance phase, the congestion window is updated as:

250ms

Fig. 2 Uplink Frame Structure

We consider a satellite with on-board processing (OBP) capability so that it takes one satellite round-trip delay (about 250 ms) for each VSAT to receive its assignment. When the satellite OBP receives the reservations in each frame, its scheduler assigns data slots to the requesting VSATs on a first-come-first-served basis. When all reservation requests are satisfied, the remaining data slots are assigned to each VSAT in a round robin manner. III.

TCP MECHANISM OVERVIEW

Different TCP versions have evolved over the years since TCP Tahoe was first implemented in 4.3 BSD in 1988. The most popular and successful one is TCP Reno. TCP Vegas was proposed by Brakmo [9, 10] in 1995. In this paper, we focus on TCP Reno, SACK and Vegas. TCP Reno and Vegas differ mainly in how they control the flow rate of a connection. A. TCP Reno TCP Reno has four basic schemes to control the congestion window: slow-start, congestion avoidance, fast retransmit and fast recovery. TCP uses two variables: congestion window (cwnd) and slow-start threshold (ssthresh) to determine how much data should be injected into the network:  cwn d + 1 ;  cwn d + 1 ⁄ cwn d ; c wn d =   cwn d ⁄ 2 ;  1; 

cwnd < ss th res h cwn d > s sth resh if 3 duplicate ACK occurs if timeout occurs

The advantage of TCP Reno lies in its adaptive retransmission and congestion control mechanism. However, TCP Reno has no mechanism to detect incipient congestion or prevent packet loss. Its performance degrades significantly when packet losses are caused by transmission errors. B. TCP SACK TCP SACK adds the Selective Acknowledgment option to TCP Reno. The SACK option field contains a number of SACK blocks, each of them represents a non-contiguous set of data that has been received and queued [11]. TCP SACK preserves the basic congestion control schemes of TCP Reno. Its benefit is to enable recovery from multiple packet losses more efficiently without triggering timeouts, thus improving throughput over error-prone links.

diff < α ⁄ b aseR TT  cwnd + 1;  cwnd =  cwnd ; α ⁄ b ase RTT ≤ d iff ≤ β ⁄ ba seRTT  cwnd – 1 ; diff > β ⁄ baseR TT  di ff = cwn d ⁄ BaseR TT – cwn d ⁄ currtt

where currtt is the currently observed RTT, baseRTT is the minimum value of measured RTTs, and α , β are thresholds which determine the extra buffers the sender can take given the current condition in the connection path. Normally, the values of α and β are fixed as 1 and 3, respectively. TCP Vegas also employs some other algorithms to differentiate itself from Reno. Readers can refer to [9, 10] for details. It is noteworthy that the Vegas slow-start scheme allows exponential growth of the congestion window only by every other RTT, which may be harmful to TCP performance over satellite links due to the long delay. The throughput performance of TCP Vegas in wired networks has been investigated widely, but this is not the case for satellite networks. It has been shown [12, 13] that the performance of TCP Vegas may be inferior to TCP Reno over long delay channels. In this paper, our simulation results reveal the conditions of this disadvantage. D. Proposed Dynamic TCP Vegas (TCP DVegas) In the satellite network topology considered (Fig. 1), the REM queues are located at the bandwidth bottlenecks, i.e., the MAC layer for the satellite uplink. In the split connection scenario, the PEP acts as virtual end-points of the cascading TCP connections. So it has full knowledge of the conditions of the underlying MAC queues. At the same time, TCP Vegas keeps an estimate of the RTT. So we can utilize this information to control the sending windows more efficiently. Information can be exchanged between TCP and MAC layers by means of service primitives, as shown in Fig. 3. To query the status of the underlying queue, the TCP layer sends a request to the MAC layer, which then responds with the value of qavg. When a packet is “marked” by the REM Proxy Receive Buffer

Clear

Transmit Buffer

TCP Layer

Request Notification

Response

Queue maxth

min th

MAC Layer

Fig. 3 Congestion Control Architecture in the Gateway

algorithm in the MAC queue, the MAC layer notifies the TCP layer about the current qavg value. We call this notification the congestion signal. When it receives a congestion signal, the TCP layer takes appropriate actions, then clears the notification. TCP Vegas uses two parameters, α and β to control the congestion window. TCP DVegas dynamically adjusts these two parameters according to both qavg and currtt. In our approach, when qavg < minthresh and currtt/baseRTT < 1.1, we increment α and β with factor (baseRTT/currtt)/2. When qavg > maxthresh or currtt/baseRTT > 1.2, we multiply α and β with factor (baseRTT/currtt)/2. The lower bounds for α and β, 1 and 3 respectively, are same as the default values in Vegas. This dynamic control of the congestion window is aimed at achieving both high throughput and low latency. Since over the satellite network TCP congestion occurs only at the REM queue, any packet losses must be caused by transmission errors. Therefore we can effectively separate TCP congestion control and error recovery, by adjusting the congestion window only in response to congestion signals from the REM queue. When a TCP sender receives an ACK, no matter whether it is a new ACK or a duplicate ACK, it checks for the congestion signal. In the presence of the congestion signal, if qavg < maxthresh, the sender reduces its window by 1/4, or 1/2 otherwise. If the congestion signal is absent, the sender keeps increasing its window as in the original mechanism. In this way, we can realize immediate feedback and separate flow control and error recovery.

throughput of the four schemes degrades significantly when the uplink bandwidth shared by the VSATs is less than 3 Mbps. There is a trade-off when bandwidth is limited. TCP DVegas and Vegas sacrifice throughput for low RTTs, while TCP Reno and SACK keep their throughput but their RTTs increase sharply. This is because TCP Vegas and DVegas use the RTT as a parameter to control their window growth. In most cases, the throughput performance of DVegas is 12% better than Reno and 5% better than TCP Vegas and SACK, while keeping similar RTTs as TCP Vegas.

Fig. 4 Impact of VSAT uplink bandwidth on throughput

As the double slow-start mechanism in the original TCP Vegas is harmful to TCP performance over satellite links, it is not used in our protocol. IV.

PERFORMANCE COMPARISONS

We use ns2 [14] as the simulation tool. The implementation includes 100 TCP connections at the VSAT side. The TCP throughput is defined as the received data bytes divided by the simulation time. The bandwidth of the satellite link is 6 Mbps while the bandwidth of the terrestrial link is 10 Mbps. For the REM queue configuration, we set minthresh and maxthresh to 5 and 15, respectively. We compare TCP DVegas with TCP Reno, DSAK and Vegas, all applied to the satellite link between the PEPs. These TCP versions are all ECN-enabled to support REM queues as they do not use cross layer congestion feedback. We set up the following traffic source to test the proposed mechanism. Each time the server transmits a 200KB file. After it is finished, it waits for an exponentially distributed time to send another 200KB file. This model approximates WWW traffic [15]. The shorter the inter-arrival time is, the heavier the traffic load is. A. Effects of MAC Protocol Figs. 4 and 5 show the impact of the uplink bandwidth on the TCP throughput as well as RTT (over satellite network only). The mean time between file transmissions is 20s. The

Fig. 5 Impact of VSAT uplink bandwidth on RTT

B. Effects of Traffic Load We investigate the effect of traffic load on TCP. The mean inter-arrival times for transferred files vary from 40s to 15s and BER is 10-7. When the load is heavy, TCP DVegas, Vegas and SACK out-performs TCP Reno as Fig. 6 shows. This is because TCP Reno needs more time to recover from dropped packets, while TCP SACK can recover quicker using selective ACKs. TCP Vegas drops only half as many packets compared to Reno due to congestion, and the immediate feedback in DVegas results in very few dropped packets. Under light load, performance of TCP Vegas is worst due to its conservative congestion control mechanism, i.e., double slow-start and small thresholds α and β. C. Effects of BER We test the impact of BER on TCP performance in a scenario where 20% of the VSATs experience a 10-6 BER, e.g.,

Fig. 6 Impact of traffic load on throughput (BER=10-7)

due to rain fades, while the rest experience a 10-7 BER. Compared to Fig. 6, Fig. 7 shows that the overall throughput does not suffer much degradation due to the adaptive mechanism of TCP. Other TCP connections will take bandwidth from those suffering from degraded BER. However, Fig. 8 shows that the proposed DVegas significantly improves the performance of those TCP connections suffering from a higher BER. This is because DVegas effectively separates the mechanism of flow control and error recovery.

for satellite networks employing PEPs. DVegas employs AQM at the MAC layer REM queue and immediate feedback to TCP senders to control congestion and separate the TCP error recovery mechanism. We have also investigated the impact of asymmetric bandwidth, different traffic load and BER on TCP performance. Simulation results show that the improvement of TCP performance realized by DVegas is significant. This dynamic TCP congestion control scheme is useful not only in satellite networks, but also in any network that benefits from the deployment of the split connection or cascading TCP; e.g., cellular and ad-hoc wireless networks. REFERENCES [1] [2] [3]

[4]

[5] [6] [7] Fig. 7

Impact of traffic load on throughput (20% VSATs with BER=10-6, 80% VSATs with BER=10-7)

V.

CONCLUSIONS

In this paper, a dynamic TCP congestion control method called TCP DVegas, which mitigates TCP Vegas’s shortcomings while keeping its merits, has been proposed

[8]

[9] [10] [11] [12] [13] [14] [15]

Fig. 8 Impact of traffic load on throughput (BER=10-6)

J. Border, M. Kojo, J. Griner, G. Montenegro and Z. Shelby, “Performance enhancing proxies intended to mitigate linkrelated degradations,” IETF RFC3135, June 2001. M. West and S. McCann, “Improving TCP performance over long-delay and error-prone links,” in Proc. IEE Seminar on Satellite Services and the Internet, pp. 1-9, 2000. V.G. Bharadwaj, J.S. Baras, and N. P. Butts, “An architecture for Internet service via broadband satellite networks,” International Journal of Satellite Communications, vol. 19, pp. 29-50, 2001. T. Hasegawa, T. Hasegawa, Y. Miyake and K. Nakao, “TCP Gateway for satellite-based Internet service accommodating multiple subscribers,” in Proc. IEEE WCNC, Orlando, FL, Mar. 2002. T.R. Henderson and R.H. Katz, “Transport protocols for Internet compatible satellite network,” IEEE J. on Sel. Areas in Commun., vol. 17, pp. 326-344, Feb. 1999. S. Floyd, R. Ramakrishna and S. Shenker, “Adaptive RED: an algorithm for increasing the robustness of RED’s active queue management”, Aug. 2001 (unpublished). K. Ramakrishnan and S. Floyd, “A proposal to add explicit congestion notification (ECN) to IP,” IETF RFC 2481, Jan. 1999. T. Le-Ngoc and J.I. Mohammed, “Combined free/demand assignment multiple access (CFDAMA) protocols for packet satellite communication,” Proc. IEEE ICUPC, pp. 824 -828, 1993. L.S. Brakmo and L.L Peterson, “TCP Vegas: end to end congestion avoidance on a global Internet,” IEEE J. on Sel. Areas in Commun., vol. 13, pp. 1465-1480, Oct. 1995. L.S. Brakmo, S.W. O’Malley and L.L Peterson, “TCP Vegas: new technique for congestion detection and avoidance,” in Proc. of ACM SIGCOMM, London, UK, pp. 24-35, Oct. 1994. K. Fall and S. Floyd, “Simulation-based Comparisons of Tahoe, Reno, and SACK TCP”, ACM Computer Communication Review, vol. 26, pp. 5-21, July 1996. S. Horan and R. Wang, “Internet-type protocol testing in a simulated small satellite environment”, in Proc. IEEE Aerospace Conference, pp. 977-989, 2001. Y. Thing, E. Yan, and S.K. Dao, “A measurement of TCP over long-delay networks,” in Proc. IEEE INFOCOM, pp. 1556-1563, March 1999. The Network Simulator ns-2, http://www.isi.edu/nsnam/ns E. Anderlind and J. Zander, “A traffic model for non-realtime traffic in wireless radio networks,” IEEE Comm. Letters, vol. 2, pp. 37-39, Mar. 1997.