Proxy Mechanism of Multiplexing TCP Connections over Satellite ...

Master’s Thesis

Title

Proxy Mechanism of Multiplexing TCP Connections over Satellite Internet

Supervisor Professor Masayuki Murata

Author Morihiro Kouda

February 13th, 2002

Department of Informatics and Mathematical Science Graduate School of Engineering Science Osaka University

Master’s Thesis

Proxy Mechanism of Multiplexing TCP Connections over Satellite Internet Morihiro Kouda

Abstract Since a satellite link provided by GEO (Geostationary Earth Orbit) Satellites has a large propagation delay, TCP performance is known to be degraded when the TCP connection is utilized between sender and receiver hosts interconnected via the satellite link. It is mainly because the window size of the TCP connection increases slowly due to the large propagation delay on the satellite link, and because the satellite network has a very large bandwidth-delay product. Ironically, this tendency becomes remarkable as the link capacity gets large. In this thesis, we propose a novel architecture of a proxy mechanism for multiple TCP connections on the Satellite Internet, to overcome the problems. The proposed architecture splits the TCP connection between the sender and receiver hosts into three connections, which are a terrestrial connection from the sender host to the sender-side ground station, a satellite connection between the sender-side and receiver-side ground stations, and another terrestrial connection between the receiver-side ground station and the receiver host. It makes us possible to configure each TCP connection according to the characteristics on each network, by which it is expected to improve the overall throughput of the data transfer. Furthermore, to avoid the throughput degradation of terrestrial connections due to the low throughput of the satellite connection, we adopt SCTP (Stream 1

Control Transmission Protocol) as a transport-layer protocol to multiplex TCP connections on the satellite link, to effectively use the capacity of the satellite link. We further propose the congestion control mechanisms adopted to the satellite SCTP connection. It is based on the congestion control mechanism of TCP Vegas, which can well match the characteristics of the satellite connection, since TCP Vegas can provide a stable available bandwidth-delay product. Additionally, we discuss the method to deal with the difference of the available bandwidth between the terrestrial connections and the satellite connection and to improve the fairness among the multiplexed TCP connections. We evaluate the performance of the proposed mechanism through numerical results of simulation experiments, and confirm that the proposed mechanism can improve the utilization of the satellite link and the fairness among multiplexed TCP connections, when compared with the traditional mechanisms.

Keywords Satellite Internet, GEO (Geostationary Earth Orbit), TCP (Transmission Control Protocol), SCTP (Stream Control Transport Protocol), Connection Splitting, Connection Multiplexing

2

Contents Abstract

5

1

Introduction

5

2

Backgrounds

9

2.1

Satellite Internet and its Problems . . . . . . . . . . . . . . . . . . . . .

9

2.2

Related Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

3

4

5

Proxy Mechanism

14

3.1

Connection Splitting . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

3.2

Connection Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . .

16

3.3

TCP Vegas-based Congestion Control Mechanism . . . . . . . . . . . . .

17

3.4

Packet Buffering at Sender-side Ground Station . . . . . . . . . . . . . .

19

Performance Evaluation

21

4.1

Simulation Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

4.2

Evaluation Results and Discussions

22

. . . . . . . . . . . . . . . . . . . .

Conclusion

25

Acknowledgements

28

Reference

28

3

List of Figures 1

Satellite Internet Model . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2

Connection Splitting . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

3

Packet Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

4

Connection Multiplexing by SCTP . . . . . . . . . . . . . . . . . . . . .

31

5

Packet Buffering at Sender-side Ground Station . . . . . . . . . . . . . .

31

6

Simulation Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

7

Relations of Bs and Throughput of Satellite Link . . . . . . . . . . . . .

32

8

Dynamics of Throughput of Each Connection . . . . . . . . . . . . . . .

32

4

1

Introduction

The amount of the network traffic is explosively increasing due to the growth of the Internet population. It makes the enormous demand for large network bandwidth, which encourages the rapid development of technologies for the high-speed networks, such as WDM (Wavelength Division Multiplexing) [1] for backbone networks, and ADSL (Asymmetric Digital Subscriber Line) [2] and cable modems for access networks. These technologies provide the high-speed terrestrial physical links in order to interconnect networks and/or endhosts. However, it is sometimes very difficult or impossible to establish those links in some regions due to the geographical reasons and the low cost-effectiveness. These regions usually exist at underpopulated areas, which causes so-called “digital divide” problems. One possible way to tackle this problem is using satellite links for the Internet access. One example can be found in the i-Space project by NASDA (NAtional Space Development Agency) in Japan [3]. In this project, a WINDS (Wideband InterNetworking engineering test and Demonstration Satellite), which is the geostationary satellite that aims to provide at faster speeds the enormous amounts of information needed in an information technology-based society. It can also provide the high-speed satellite link for the Internet access only by setting up a ground station at any point where we want to connect to the Internet. It also enables the cost-effective usage of the satellite link resource, which means that the satellite link is utilized only for downstream links and upstream links are realized by using the existing terrestrial links. Another example can be found in the satellite Internet access realized by Gilat-to-Home Inc [4]. It provides the bi-directional accessibility to the Internet by satellite links. The satellite network has some problems due to its inherent nature. Since satellite 5

networking is realized by the wireless radio communication, its performance tends to be affected by air condition, the ionosphere, and other weather factors, that causes higher bit error rate (BER) than existing wired links. FEC (Forward Error Collection) and ARQ (Automatic Repeat reQuest) technologies can help reducing the BER at the expense of adding redundancy, which is well discussed by many researchers ([5][6][7] and references therein). The another problem, on which we focus in this thesis, is a large propagation delay provided especially by the GEO (Geostationary Earth Orbit) satellite network. When we use the satellite Internet constructed by GEO satellites, the large propagation delay causes the serious performance degradation in data transfer by TCP (Transmission Control Protocol) [8], which is the most popular transport-layer protocol in the current Internet [9]. It is mainly because the congestion control algorithm of TCP does not match the large capacity (bandwidth-delay product) of the satellite link. That is, it can’t utilize the bandwidth of the satellite link effectively since it takes much time to increase the window size of the TCP connection to fill up the bandwidth-delay product of the link. Some researchers have tried to solve the problem [10][11][12], but no effective and complete method has been proposed. In this thesis, therefore, we propose a novel proxy mechanism for TCP connections over satellite to overcome the above-mentioned problem. The proposed mechanism has two major features, which are connection splitting and connection multiplexing. It first splits the TCP connection between sender and receiver hosts into three connections, which are two terrestrial connections and a satellite connection. By connection splitting, we can avoid the unnecessary throughput degradation at the terrestrial connections caused by a low throughput of the satellite connections. For improving the throughput of the satellite link, we multiplex TCP connections on the satellite link into a single connection with

6

SCTP (Stream Control Transport Protocol) [13]. Then we can avoid the problem of the small TCP window size, since all packets from the TCP connections can be transferred by the SCTP connection having the large window size. We show the detailed mechanisms of multiplexing TCP connections into the SCTP connection, which includes the header translation algorithm of TCP/SCTP packets. We further propose the congestion control mechanisms adopted to the satellite SCTP connection. In the original SCTP, a TCP Reno-based congestion control algorithm is used. However, its control algorithm is inappropriate on the satellite link since it does not match the characteristics of the satellite link. Noticing that the available capacity of satellite link is comparatively stable, a TCP Vegas-based congestion control mechanism [14] can well match the characteristics of the satellite connection, providing stable bandwidthdelay product. Therefore, we introduce the congestion control mechanism of TCP Vegas on the SCTP connection. We further notice that TCP Vegas can show further better performance than TCP Reno when only one TCP connection exists in the network[15, 16]. Fortunately, our proxy mechanism establishing a single SCTP connection multiplexing multiple TCP connections on the satellite link, and well suitable to the current situation. We also introduce the mechanism for packet buffering at the sender-side ground station, to deal with the difference of the available bandwidth between the terrestrial connections and the satellite connection. Another merit of our proposed mechanism is that the sender and receiver hosts have no need to become aware of connection splitting and multiplexing by the proxy mechanism on the satellite link, and we can provide the seamless accessibility to the Internet regardless of the difference in the underlying physical network architecture. We believe that it is a very important feature to cope with the heterogeneity of the Internet.

7

We evaluate the performance of the proposed mechanism through simulation experiments, and confirm that the proposed mechanism can improve the utilization of the satellite link and the fairness among multiplexed TCP connections, compared with the traditional mechanisms. The rest of this thesis is organized as follows. In Section 2, we describe the backgrounds of the satellite Internet and the problems in TCP data transfer over the satellite Internet. Our proposed mechanism which resolve those problems is then presented in Section 3. In Section 4, we evaluate the effectiveness of the proposed mechanism through some simulation experiments. Finally, we conclude this thesis and describe some future work in Section 5.

8

2

Backgrounds

2.1

Satellite Internet and its Problems

Communication satellites that occupy the open air are categorized into three classes according to the orbit altitude, which are GEO (Geostationary Earth Orbit) satellites, MEO (Medium Earth Orbit) satellites, and LEO (Low Earth Orbit) satellites. A GEO satellite has the highest altitude of 36000km from the ground. It can then provide the widest communication range among the three types of satellites. The whole ground of the earth can be covered by three GEO satellites. However, the high altitude of the GEO satellite also brings a large propagation delay between the satellite and the ground station, which is about 250 to 300msec. On the other hand, the altitude of a LEO satellite is about 500– 2000 km, which corresponds to ??–??msec of the propagation delay, much smaller than that of the GEO satellite. Therefore, the size and the transmission power of antennas at the ground station can be also reduced by using the LEO satellites. One of the shortcomings of the LEO satellite is its narrow communication area. Then many LEO satellites must be utilized to realize the complete coverage of the earth ground. Furthermore, since the LEO satellites are not geostationary and they have about two hours of a rotation period, many satellite-to-satellite handoffs occur in LEO satellite communication. Therefore, it is necessary to construct a complex network system to provide a stable communication service by LEO satellites. A MEO satellite has 8000–20000 km altitude, so it has the middle characteristics between GEO and LEO satellites. In this thesis, we focus on the satellite Internet realized by the GEO satellites, which are used in the current satellite Internet services. Figure 1 depicts the model for the satellite Internet considered in the thesis. It consist

9

of a sender host which transfers data to the user, a receiver host which corresponds to the user’s terminal, sender-side/receiver-side ground stations which are the gateways between the satellite network and the sender-side/receiver-size terrestrial networks, and a GEO satellite. Using this system, we focus on the data transfer from the sender host to the receiver host by using TCP, which is activated by the typical Internet services such as WWW (World Wide Web) and file transfers. In the satellite Internet, the TCP connection traverses three different networks; the sender-side terrestrial network from the sender host and the sender-side ground station, the satellite network between the ground stations via the GEO satellite, and the receiverside terrestrial network from the receiver-side ground station to the receiver host. Since the satellite network has very large propagation delay, the RTTs (Round Trip Times) of the TCP connection also become large. The problem is that the throughput of a TCP connection seriously degrades when RTT is large, that has been revealed in many previous researches [9][17][18]. There are several reasons for the throughput degradation. First, since the window size of the TCP connection increases by one packet per a RTT during the congestion avoidance phase [19], the large RTT caused by the satellite network degrades the speed of increasing the window size. Furthermore, the satellite link has a large capacity (a network bandwidth-delay product), it takes much time to fill up the capacity by the TCP connection’s window. This throughput degradation becomes more apparent especially when the transferring data size is small, which can be frequently found in Web document transfers. Furthermore, since the default value of the maximum window size of the sender TCP is 64 KBytes, the TCP connection can’t utilize the capacity of the satellite link even in the large document transfer. The maximum window size is also limited by a receive

10

GEO Satellite GEO

Satellite Link Terrestrial Link

Terrestrial Link

SH

SGS

RGS

Sender Hosts

Sender-side Ground Station

Receiver-side Ground Station

RH Receiver Hosts

Figure 1: Satellite Internet Model

buffer size at the receiver TCP, which is initially set to, e.g., 16 KBytes in FreeBSD 4.0 system [20]. One may consider that a Window Scale option [21] can help solving the problem. However, the window scale option is designed for configuring the maximum window size at the sender host according to the buffer size at the sender and receiver hosts. That is, it can’t be adapted to the capacity of the network that the TCP connection passes through. Therefore, the window scale option can’t work effectively in the satellite Internet, since the sender and the receiver hosts do not know the characteristics of the intermediate networks.

2.2

Related Works

Some mechanisms we’ve seen proposed to dissolve the problems mentioned in the previous subsection [9][11][12][22][23]. In [22], the authors has proposed to utilize both of the Path MTU Discovery mechanism [19] and the Window Scale option. The Path MTU Discovery mechanism is used to set the packet size to a very large value for the satellite link. It can relatively reduce the packet header overhead, and it also improves the data 11

transmission rate by TCP since the TCP window size is controlled in a unit of packet. The authors has also presented the dynamic control mechanism of the receive buffer size according to the congestion window size, to dissolve the problems in the Window Scale option described above. However, since it assumes to be used only on the satellite link, it can’t be applied to our network model, where the TCP connection traverses both of the terrestrial and satellite networks. That is, when the MTU of the terrestrial link is smaller than that of the satellite link, the packet size is set to that of the terrestrial link. Furthermore, since it is very difficult for the TCP sender to determine the characteristics of the network in advance, the appropriate setting of the sender TCP is impossible. In [11][23], the mechanisms were proposed to split the TCP connection into some connections according to the characteristics of the underlying networks. [11][23] focus on data transfer via both of the wireless radio network and the wired network, and present the mechanism to use two TCP connections, that is one TCP connection on the wireless network, and another is on the wired network. It makes us to configure each TCP connection according to the characteristics on each network, by which it is expected to improve the overall throughput of the data transfer. However, there mechanisms do not consider the network with very large propagation delay such as the on current case of GEO satellite network. The authors in [12] have been proposed to share the state variables of the single TCP connection, including the window size, among multiple TCP connections on the satellite link. By this mechanism, all of the TCP connections can utilize the shared window, which is large enough to exhaust the capacity of the satellite link. Then the utilization of the satellite link improves. However, it cannot be applied to our case, where the TCP connections is originated from the sender host at the terrestrial network, thus they cannot

12

share the state variables effectively. The another problem is that most of the above mechanisms require some modifications at the sender/receiver hosts. When we consider the actual implementation, it is impossible to apply the proposed mechanism to all of the hosts using the satellite network. Furthermore, if we implement the mechanism at some of the hosts, the unfairness problem between the enhanced hosts and traditional hosts becomes apparent. Therefore, we want to a mechanism that does not require any changes at the sender/receiver hosts; The proxy mechanism we propose in this thesis can realize it.

13

3

Proxy Mechanism

In this section, we propose a proxy mechanism for TCP connections via the satellite link to avoid performance degradation. We introduce the details of the proposed mechanism, which includes connection splitting, connection multiplexing, TCP Vegas-based congestion control mechanism, and packet buffering at the sender-side ground station.

3.1

Connection Splitting

As explained in the previous section, the throughput of a TCP connection via the satellite link decreases since the RTT of the connection is large due to the propagation delay of the satellite link. It also degrades the throughput of the terrestrial connections, which usually have larger link bandwidths than the satellite connection. To overcome this problem, the proposed scheme splits the TCP connection between the sender host and the receiver host into three connections, which are a sender-side terrestrial connection between the sender host and the sender-side ground station, a satellite connection between the sender/receiver-side ground stations, and a receiver-side terrestrial connection between the receiver-side ground station and a receiver host. Figure 2 depicts the timing chart of packet transmission using the three connections. In the figure we assume that all of the three connections use TCP in data transfer. When the sender-side ground station receives data packets from the sender host, it immediately sends ACK packets back to the sender host and passes the data packets to the satellite connection. Then the sender host receives the ACK packets in small RTTs, which are not affected by the large propagation delay of the satellite link. That is, since the split three connections can transfer data effectively according to the available link bandwidths, the

14

GEO Satellite Sender-side Ground Station

Sender Host

Receiver-side Gound Station

Receiver Host

SYN SYN

SYN+ACK SYN+ACK ACK+Data1 ACK1 Data2,3 ACK2,3

ACK Data1 Buffering

Data1

SYN SYN+ACK ACK

Data1 Buffering ACK+Data1 ACK1

ACK1 Data2,3 Data2,3 Buffering

DataN+FIN

Data2,3 Buffering Data2,3

ACK2,3 ACK2,3

FIN+ACK

DataN+FIN DataN+FIN FIN+ACK

Sender-Side Terrestrial Connection

Satellite Connection

Figure 2: Connection Splitting

15

FIN+ACK

Receiver-Side Terrestrial Connection

sender/receiver-side terrestrial connections can improve their throughput without influences of the low throughput and the large delay of the satellite connection. However, a problem arises in connection splitting. Since the sender-side ground station transmits ACK packets to the sender host just after it receives the data packets from the sender host, the sender host is notified the receipt of the data packets before they actually arrive at the receiver host. This violates the reliable data transmission criteria provided by TCP [19]. In the proposed mechanism, therefore, the sender-side ground station is responsible for the transmission of the data packets to the receiver-side ground station, on behalf of the sender host. That is, the sender-side ground station keeps the copy of the data packets until it receives the ACK packets from the receiver-side ground station, as shown in Figure 2. Similarly, the receiver-side ground station is also responsible for reliable transmission of the data packets to the receiver host. It means that the receiver-side ground station discards the packet copies after it receives the corresponding ACK packets from the receiver host. Note that our mechanism uses the normal packet transmission mechanism in the connection setup phase, to carefully check the availability of the intermediate links and ground stations from the sender host and the receiver host, as shown in Figure 2. We should also consider a situation where the sender/receiver ground stations break down after the three connections are established. One possible solution is to use the normal packet transmission mechanism in the connection closing phase. A more detailed discussion will be done in the future work. Due to one important objective of the proposed mechanism that it poses no modifications on the protocol stacks at the sender/receiver hosts, the connection splitting has another problem in packet forwarding at the sender/receiver-side ground stations. Since in the proposed mechanism the sender/receiver hosts are not aware that the TCP connec-

16

GEO Satellite

Sender Host

Sender-side Ground Station

Receiver-side Gound Station

Receiver Host

IP address: SH

IP address: SG

IP address: RG

IP address: RH

Payload

SH RH

TCP Packet

Encapsulation

Payload

SH SG RH RG

Decapsulation

SCTP Packet

SH RH TCP Packet

Payload

Figure 3: Packet Encapsulation

tion is split at the satellite link, the destination address of data packets from the sender host is the receiver host, not the sender/receiver-side ground stations. This is a different point from other proxy mechanisms such as a Web proxy system, where a Web client host explicitly designates a Web proxy server in obtaining a Web document from a Web server. Furthermore, the addresses must be restored when the data packets finally arrives at the receiver host. In our mechanism, therefore, the sender/receiver-side ground stations change the source and destination addresses of the data packets by using the packet encapsulation as shown in Figure 3. In this mechanism, the data packets from the sender host are encapsulated into the packet of the satellite connection at the sender-side ground station and transferred to the receiver-side ground station. They are then decapsulated to the original packets at the receiver-side ground station and transmitted to the receiver host. Note that the ACK packets corresponding to the data packets are not necessary to be transmitted back to the sender host, because the sender host has already received the ACK packets from the sender-side ground station, as shown in Figure 2.

17

GEO Satellite

Sender Host

Sender-side Ground Station

Receiver-side Gound Station

Receiver Host

SCTP Streams

Satellite SCTP Connection Receiver-side Terrestrial TCP Connections

Sender-side Terrestrial TCP Connections

Multiplex/Demultiplex TCP Connections to a SCTP conection

Figure 4: Connection Multiplexing by SCTP

3.2

Connection Multiplexing

Connection splitting described above can help avoiding the throughput degradation of the terrestrial connections caused by the satellite connection. However, the throughput of the satellite connection cannot be improved by connection splitting solely, since the low throughput of the satellite connection is due to its own large propagation delay. Therefore, we introduce a connection multiplexing mechanism, where TCP connections on the satellite link are multiplexed into one connection with SCTP (Stream Control Transport Protocol) [13]. TCP defines a stream as a data flow in units of bytes. On the other hand, SCTP defines it as a data flow in units of data chunks received from the upper layer, and it has a mechanism to treat multiple streams in one SCTP session in data transmission. This is the reason why we adopt SCTP as a transport-layer protocol at the satellite connection to multiplex TCP connections. As shown in Figure 4, it can be done by regarding each TCP connection as a SCTP stream to be multiplexed into one SCTP session established on the 18

satellite link. Generally, the window size of a new TCP connection is initially set to one packet [19]. Therefore, when we transmit data from the sender host to the receiver host by a single TCP connection in the satellite Internet, we cannot obtain enough throughput since the TCP connection cannot utilize the capacity (bandwidth-delay product) of the satellite link effectively. The throughput degradation becomes distinguishable in small data transfer, since the transfer is finished before the window size becomes enough large. In the proposed mechanism, on the other hand, the TCP connections on the satellite link are multiplexed into a single SCTP connection, so that they could share the window size of the SCTP connection to transfer their packets. Therefore, once the SCTP connection inflates its window size enough, a newly arriving TCP connection can also use the large window of the SCTP connection from the beginning of the data transmission. It is expected to improve the throughput of the TCP connection significantly.

3.3

TCP Vegas-based Congestion Control Mechanism

SCTP uses the congestion control mechanism adopted in TCP Reno [19]. It is based on the consideration that TCP-friendliness is an important aspect when we deliberate the deployment of SCTP, since TCP is the most popular transport-layer protocol in the current Internet. However, the TCP Reno-based congestion control mechanism is not appropriate to be used at the satellite SCTP connection due to the following reasons; • Since the satellite link is usually used for point-to-point communication, a single SCTP connection occupies the satellite link in the proposed mechanism. So network congestion does not occur on the satellite link. The TCP Reno-based congestion control mechanism does not match such a situation since it depends on the 19

packet loss to regulate its window size. • The satellite link has a stable size of the bandwidth-delay product, so TCP Reno’s window size control algorithm is not suitable since it continues increasing the window size when no packet loss occurs. In the proposed mechanism, therefore, we use the congestion control mechanism of TCP Vegas [14]. This is because some researches including [15, 16] have reported that TCP Vegas shows much better performance than TCP Reno especially when only one TCP connection exists in the network, which is just the same situation as in our mechanism. TCP Vegas controls the window size by observing changes of RTTs of transmitted packets. If observed RTTs become large, TCP Vegas recognizes that the network begins to be congested, and throttles the window down. If RTTs become small, on the other hand, TCP Vegas determines that the network is relieved from the congestion, and increases the window size. Then, the window size in an ideal situation becomes converged to the appropriate value and no packet loss occurs in the network, which results in throughput improvement of the TCP connection. In the congestion avoidance phase, TCP Vegas updates its window size as;

cwnd =

diff =

                

cwnd + 1, if diff