TCP/IP PERFORMANCE OF ASYMMETRIC SATELLITE LINK AND MOBILE IP LINK OVER WIRELESS LAN Jae H. Kim,* Senior Member, IEEE , Jeffrey P. Harrang, Member, IEEE, Boeing Phantom Works P.O. Box 3999, MS 3W-51, Seattle, WA 98124-2499 (253) 657-7685 (TEL), 657-8903 (FAX) and Arun Ayyagari, Member, IEEE, Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Abstract The issues related to TCP/IP implementation in fixed and mobile environments are being investigated for a variety of commercial and DoD applications. Specific issues are the effects of disadvantaged links associated with bandwidth, latency, and traffic asymmetries, high bit error rates, quality of service, and security requirements on network operation. We set up a “TCP/IP Network Testbed for Mobile Platforms,” which enables us to simulate a wide range of network topologies such as asymmetric satellite links, mobile IP links (host mobility and router/network mobility under development), and wireless LANs (IEEE 802.11B). In this paper, we will focus on TCP/IP throughput performance of a simulated asymmetric satellite link. We also describe the operation of host mobile IP (router or network mobility in the future) over wireless LANs. 1. Introduction Boeing has been working on satellite broadband data services (known as Global Mobile Services) to provide airborne information services to government platforms, commercial airlines, and business jets. These services offer Internet access (e.g., in-flight web browsing, e-commerce) to remote locations and corporate virtual private network connectivity (e.g., email, file transfer) to customers on the move and also support live and pre-recorded broadcast video/audio and crew-information data. Since the real-world systems will use broadband satellite channels for a forward link to the mobile platform and narrowband RF channels for a return link to the *
ground station, the systems have to deal with bandwidth, latency, and traffic asymmetries. The performance of communications protocols (e.g.,TCP/IP) and applications over satellite systems has been an ongoing research issue [1-3]. Boeing is involved in investigating the issue related to TCP/IP implementation for both fixed and mobile environments in a variety of commercial and military applications. Applications involve providing a full range of information services to users on board mobile platforms on a global scale, and battlefield networks serving a combination of mobile and fixed elements in theater. Specific issues are the effects of disadvantaged links associated with bandwidth/latency asymmetries, high bit error rates, quality of service, and security requirements on network operation. We have set up a “TCP/IP Network Testbed for Mobile Platforms” that is capable of simulating and testing a wide range of networks such as an asymmetric TCP/IP and mobile IP over wireless LAN. In this paper, we will focus on TCP throughput performance of the asymmetric satellite link and mobile IP over wireless LAN. 2. Link Asymmetry Effects Our test configuration represents a typical scenario on a mobile platform where the user connects to the corporate Intranet via an onboard LAN. The main characteristics of the end-to-end path in this configuration that affect the performance of transport protocols are bandwidth, latency, and traffic asymmetries with high bit-error rates. These characteristics with long delays and high bit error rates over GEO satellite links tend to seriously affect the TCP/IP performance. Thus, with a TCP/IP network testbed we have evaluated the effects of high bandwidth, latency, and traffic asymmetries on TCP performance
Point of Contact E-mail:
[email protected]
1
under fixed bit-error rates (BER). We fixed a BER to focus on the effects of bandwith and latency asymmetries. We also note that typically the BER can be corrected with a proper error correction techniques in the actual satellite links. From earlier testing on typical server-to-client operation, we determined that the traffic asymmetry for applications performing typical ‘pull’ operations, such as receiving email, web browser, and remote file access ranges from 10:1 to 20:1 (forward to reverse traffic ratio). We define ‘forward’ to mean traffic flowing from the ground to the mobile platform and ‘reverse’ to mean the opposite. Therefore, if a session on the airplane were to use the data channel, e.g., 4.8 kbps, on the reverse link, the maximum achievable forward link throughput is 48 kbps assuming 10:1 traffic ratio. Anything beyond this rate would be limited by the reverse channel bandwidth. The traffic asymmetry ratio therefore limits the maximum data throughput into the airplane. This analysis obviously ignores other limiting factors such as congestion on the shared forward link which might further reduce the maximum potential throughput. While a transport layer (TCP) splitting solution such as SkyXpress (SkyX) Gateway would not help these traffic asymmetry issues, it would improve the performance of simple applications (e.g., FTP) that have minimal application layer interaction. The SkyX gateway TCP performance test will be described in Section 4.
passes through non-TCP traffic (e.g., UDP, ICMP, VPN encrypted data). The SkyX gateway splits the end-to-end TCP connection into three separate segments; a TCP connection between a client and a client-side SkyX gateway, a SkyX protocol satellite connection between two SkyX gateways, and a TCP connection between a server-side SkyX gateway and a server. Subnet 1 Exch Server
Web Server
1.5 Mbps Satellite Link Simulator
Subnet 2
Ground Router
LAN 1 PPTP SkyX Server Gateway
PSTN Link Simulator
Exch Client Airborne Router
LAN 2
SkyX Gateway
2.4-38.4 kbps
Figure 1: Asymmetric Satellite Link Testbed 4. SkyX Gateway TCP Performance over Asymmetric Satellite Link The links are configured to broadband (1.5 Mbps) to represent the forward satellite channel and narrowband (2.4-38.4 kbps) to represent the reverse channel (e.g., via air phone), with variable round-trip delay times (RTT up to 1000 ms) on either channel. TCP/IP throughput testing was performed over asymmetric satellite links with various applications such as file transfer protocol (FTP), web browsing, and e-mail retrieval. These tests were performed with and without SkyX gateway protocols, for comparison.
3. TCP/IP Testbed for Mobile Platforms Our TCP/IP network testbed (Figure 1) consists of Cisco 3640 Modular Routers, Adtech SX-13 Satellite Channel Simulators, Mentat XR-10 SkyX Gateways, and various servers including Microsoft Internet Information Service (IIS) NT Server, Pointto-Point Tunneling Protocol (PPTP) Server, and Exchange Server. The client and server TCP/IP stacks were intentionally not tuned from their default settings since in actual systems the network operator will not have control over what equipment customers use to pass data over the network. This means, for example, that the default 8 kB maximum window size was used during the testing (more recent versions of Windows have increased this default to 16 kB). SkyX Gateway is designed for TCP traffic, replacing TCP with the proprietary SkyX protocol optimized for satellite conditions. It transparently
M axim u m C o ntin uo us T hro ugh put L to C lien t T ran sfer 1.06M B FT P S erv er
T h ro u g h p u tkb ( p s)
1600. 0 1400. 0
SX 4.8k
1200. 0
SX 9.6k SX 19 .2k
1000. 0
SX 38 .4k 4.8k
800. 0
9.6k 19.2k 38.4k
16X
600. 0
M a x 8 kB T SkCyP
400. 0
X M a x 8 kB TCP
200. 0 0. 0 0
10 0
20 30 0 cy R T T /2 0 (m s) L aten
40 0
50 0
Figure 2: FTP Performance with and without SkyX
2
The SkyX gateway showed an improved FTP throughput by 16 times as shown in Figure 2. Note that the round-trip times are expressed by RTT/2 in Figures 2 to 8. The use of large TCP window, negative ACK (NACK), and elimination of congestion avoidance in a SkyX protocol provides performance improvement of TCP layer-dominant applications (e.g., FTP) that do not interact much with the server during data transfers. However, in Figures 3 and 4, there is little to no improvement for typical HTML web page such as the CNN front page (1 MB). Unlike a large number of small files transfer, the SkyX protocol provides some improvement in situations where the end connections have a chance to ramp to their peak rates and the HTTP exchanges Are relatively few. A three-fold improvement was observed with SkyX gateways at RTT corresponding to the GEO satellite latencies. Figures 7 and 8 show an example of a large email retrieval from a remote
100
200
300
400
500
Latency RTT/2 (ms)
Figure 4: Web Performance with SkyX gateway for a Large Number of Small Files corporate exchange server. There is little to no difference with or without the SkyX Gateway. In this case, the Remote Procedure Call (RPC) interchanges between the client and the server pace the application throughput. The email retrieval test (Figures not shown) with PPTP encryption made the performance worse by 30-50 % due to more PPTP overhead. Based on the applications testing, the SkyX Gateway showed its primary benefit for TCP-dominant applications (e.g., FTP) as expected. Thus, we conclude that the TCP performance of applications over asymmetric satellite
3
links is more limited by the upper-layer client/server transactions rather than the TCP flow control mechanisms. Obviously, this problem can be addressed by specially designing smart client/server applications for use over high bandwidth-latency
links, although this is not commonly done Today. This points out why it is important to go above the transport layer in evaluating real-world high bandwidth-latency link performance.
Maximum Continuous Throughput versus Latency Browser Pull of '1MB Image Page'
Maximum Continuous Throughput versus Latency Browser Pull of '1MB Image Page' w/ SkyX Protocol large 4.8k
700.0
large 9.6k
1400.0
large 19.2k
large 4.8k
600.0
large 38.4k
large 9.6k
1200.0
Max 8kB TCP Max 8kB TCP
large 38.4k
Throughput (kbps)
Throughput (kbps)
large 19.2k
500.0
Max 8kB TCP
400.0
Max 8kB TCP
300.0 200.0
1000.0 800.0 600.0 400.0 200.0
100.0
0.0
0.0 0
100
200
300
400
0
500
100
200
Maxiumum Continuous Throughput versus Latency Email Retrieve 400. 0 1.544/9.6
300. 0
1.544/38.4
300.0 1.544/4.8
Throughput ( kbps)
1.544/9.6 fast mode
Throughput ( kbps)
1.544/9. 6 1.544/19. 2 1.544/38. 4 1.544/4. 8 TCP MaxThroughput 1.544/1.54 4
350. 0
1.544/19.2
250.0
500
Maxiumum Continuous Throughput t EmailLRetrieve w/ SkyX Protocol
400.0
350.0
400
Figure 6: Web Performance with SkyX Gateway for a Single Large 1.0 MB Satellite Image
Figure 5: Web Performance without SkyX Gateway for a Single Large 1.0 MB Satellite Image
TCP MaxThroughput
200.0
150.0
250. 0 200. 0 150. 0 100. 0
100.0
50.0
50.0
0.0 0
0.0 0
300
Latency RTT/2 (ms)
Latency RTT/2 (ms)
100
200
300
400
500
100
200
300
400
500
Latency RTT/2 (ms)
Latency RTT/2 (ms)
Figure 8: Email Retrieval Performance with SkyX Gateway for 1.06 MB E-mail
Figure 7: Email Retrieval Performance without SkyX Gateway for 1.06 MB E-mail
4
5. Mobile IP Testbed for Mobile Platforms Mobile IP [4] is designed to enable nodes to move from one IP subnet to another while retaining a fixed logical address. It is suitable for mobility across both homogeneous media (e.g., between two Ethernet segments) and heterogeneous media (e.g., between Ethernet and wireless LAN segments). The greatest advantage of providing mobility at the IP layer is that it provides application transparency, by way of a (possibly virtual) home network extending over the entire internet. This facilitates location independent access to computing resources and continuous connectivity. Simply speaking, mobile IP is based on the three basic functions: Agent discovery, Registration/Mobility binding, and Tunneling. Every mobile computer has a static IP address called a home address (on its home network). Each mobile node has a home agent (HA) on its home network. When the mobile node is away from home, it registers its care-of-address with the HA on whatever IP subnet it is visiting. A care-of-address is provided by a mobility agent called a foreign agent (FA). Home Agents and Foreign Agents may advertise their availability on each link for which they provide service. A newly arrived mobile node can send a solicitation on the link to learn if any prospective agents are present. The home agent then tunnels datagrams to the care-of-address of the mobile node when it is away from home and also maintains current location information of the mobile node. The foreign agent detunnels and delivers datagrams to the mobile node that were tunneled by the mobile node’s home agent.
mobile IP handover was performed from HA (subnet 1) via FA-1 (subnet 2) to FA-2 (subnet 3) and back to HA (subnet 1) smoothly during NetMeeting over wireless LAN.
Subnet 3
Mobile Node
PC
PC
LAN 3
PC
PC
Router (FA-2) AP
Wireless LAN
Wireless LAN
Subnet 2
Subnet 1 PC LAN 1
Mobile Node
AP
AP
Router (FA-1)
Router (HA)
PC
PC LAN 2 PC
Figure 9: Host and Network Mobile IP Testbed
Figure 10 shows an example of available mobile IP mobile client software such as Toshiba MobileGate [5], IKV++ GmbH RoamIn [6], and SUN Solaris Mobile IP [7]. The compatibility of such mobile clients was tested with Cisco mobile agents (HA and FA). Future versions of Toshiba MobileGate v0.50 are expected to conform to the latest Mobile IP draft (2002bis) and add reverse tunneling and line connect/disconnect detection features. Versions for NT 4.0 and Windows 2000 are being developed by Toshiba. SUN Solaris mobile IP also works with Cisco mobile agents while IKV++ RoamIn works only with their own mobile agents at present. Available Mobile IP Mobile Clients Toshiba MobileGate v0.32 (v0.41 available) [5]
6. Mobile IP Test over Wireless LAN link: Host Mobility Our Mobile IP testbed (Figure 9) is implemented with Cisco 3640 Routers - one for a home network router as home agent, another for a visiting network router as foreign agent, the third for a future airborne mobile router, Toshiba MobileGate for mobile client nodes (laptop PCs), and IEEE 802.11B Lucent WavePoint-II wireless LAN bridges for access points, optional range extender antennas, and external omni-directional antenna for outdoor use. The Microsoft NetMeeting applications such as audio, video, file transfer, and whiteboarding were tested with mobile IP over wireless LAN. The
Required Platform O/S Windows 95/98
IKV++ GmbH Windows RoamIn v2.0 [6] NT SUN Microsystems Linux Solaris Mobile IP [7]
Compatible Mobile IP Mobile Agents Cisco Mobile IP Mobile Agents (HA, FA) IKV++ Mobile IP Mobile Agents SUN Mobile IP Mipagents, or Cisco Mobile IP Mobile Agents
Figure 10: Available Mobile Clients Software and the Compatibility with Cisco Mobile Agents
5
In addition to host mobility of mobile terminals, we are also investigating network (router) mobility to address the problem where entire network segments are mobile. This will be briefly described in the following section 7. 7. Mobile IP Test over Wireless LAN link:
Acknowledgments
The authors thank S. Ray (AT&T Wireless) for valuable discussions at Boeing and John Ehrenberg for his encouragement and support. This work was sponsored by Boeing Global Mobile Services and Independent R&D programs.
Network Mobility Mobile platforms can carry multiple on-board local area networks (mobile LANs) that may be linked together for providing extended wide area networks (mobile WANs). The particular example of interests is a system of satellites providing coverage to a collection of mobile platforms that traverse multiple coverage areas. In this case, the mobile LAN is moving and thus changing its attachment points to the WAN and its link topology changes relatively to the fixed LAN. The problem is added by the need to maintain ongoing user sessions without any perceived interruption during handover. Our current activities for the network/router mobility solution include enhancements to commercially available or public domain mobile IP software packages for support of mobile routers, as well as proprietary laboratory implementation and testing of commercial routers.
References [1]
M. Allman et al., “Enhancing TCP over Satellite Channels using Standard Mechanisms,” IETF RFC2488, 1999.
[2]
T. Henderson and R. Katz, “Transport Protocols for Internet-Compatible Satellite Networks,” IEEE JSAC, Vol.17, No.2, p.326, 1999.
[3]
H. Balakrishnan, V. Padmanabhan, and R. Katz, “The Effects of Asymmetry on TCP Performance,” Mobile Networks and Applications, 4, p.219, 1999.
[4]
C.E. Perkins, “IP Mobility Support,” IETF Network Working Group RFC 2002, October 1996; also refer to Mobile IP: Design Principles and Practices, Addison-Wesley, 1998.
[5]
http://210.232.8.1/.19991220lksdjfsdfweil/inst04.pdf/;
MobileGate by Toshiba
8. Summary We demonstrated a “TCP/IP Network Testbed for Mobile Platforms,” which allows for simulating asymmetric satellite links, mobile IP links, and wireless LAN (IEEE 802.11B). Segmented TCP performance with SkyX gateways was described over asymmetric satellite links. Compatibility test of mobile clients was performed with mobile agents.
[6]
http://www.roamin.com/; “RoamIn Mobile IP.” By IKV++ GmbH
[7]
http://playground.sun.com/pub/mobile-ip/; “Solaris Mobile IP: Design and Implementation.”
6
