The effect of Mobile IP handoffs on the performance of TCP

Transcription

1 Mobile Networks and Applications 4 (1999) The effect of Mobile IP handoffs on the performance of TCP Anne Fladenmuller a and Ranil De Silva b a Alcatel CIT, Software Department, Route de Nozay, Marcoussis Cedex, France b School of Computing Science, University of Technology, Sydney, P.O.Box 123, Broadway, NSW 2007, Australia Mobile IP is a standard for handling routing for hosts that have moved from their home network. This paper studies the costs of the Mobile IP handoff that occurs when a mobile host moves between networks. Experiments were carried out with Mobile IP and TCP over varying network conditions to observe the effect of handoffs on the transmission. This paper shows that although Mobile IP may be appropriate for current applications, its long handoff periods make it unsuitable for the future. 1. Introduction Mobile computing has become more popular due to the increased availability of portable computers and increased popularity of networking. To be able to communicate with a mobile host, data must be transparently transmitted to the host independently of the location given by its IP address. This is achieved through mobile routing protocols like Mobile IP. When a mobile host moves between two foreign networks, a handoff is necessary to adjust the mobile routing functionality. In the future, with the combined development of mobile applications and wireless networks, users will have more freedom to move between various networks. With the increased user mobility, handoffs will become a key performance issue. We have conducted experiments, with varying network conditions, to observe the effect of handoffs on higher layer protocols like TCP. 2. Mobile computing We identify three main problems dealing with mobility in the Internet mobile routing, wireless protocol support and mobile application support. The first problem deals with the IP address which has two uses in the Internet to provide a unique identification for a network interface and secondly to provide routing information about this interface. When a computer becomes mobile, the IP address is still used to identify the network interface but it no longer indicates the location of the mobile computer. This causes normal Internet routing to fail. A number of different techniques have been proposed to solve this problem one such solution is the Mobile IP standard. The second problem involves protocol support for wireless networking technologies which have been integral in the development of mobile computing. Wireless network technologies have different characteristics than fixed networks and traditional protocols result in poor performance when operating over wireless networks. The third problem identified with mobile computing is the support for mobile applications. Mobile computers currently are likely to be disconnected from the network for large periods. This could be the result of power saving measures on power-limited computers or due to a lack of network connectivity when moving. Mobile applications must be able to survive this and to maximise time when connected on the Internet. In addition, with mobility, applications will evolve and will have to support new services like location dependent behaviour. For this to occur there must be proper services present to aid application development. This paper is focused on the first problem of mobile routing and in particular one facet of it the handoff that occurs when a mobile computer moves between different networks. 3. Mobile routing 3.1. Mobile IP The aim of Mobile IP [5] is to hide the movement of the mobile host to the upper layer protocols and applications. The mobility of the host is hidden through the use of home and foreign agents that handle the routing of packets to the mobile host. This is achieved through encapsulation of IP headers. If the mobile host is at its home network, then packets can be routed to it using normal routing. If the mobile host moves to a foreign network, the mobile host registers with its home agent to forward any packets addressed to the mobile host via the foreign agent. The packets arriving are encapsulated in a new IP header and sent to the foreign agent. The packet is routed through the network using this new header. At the foreign agent, the new header is removed and the packet is sent to the mobile host. When the mobile host returns to its original network, it deregisters with the home agent and packets are again routed to its normal location Other solutions A number of other solutions have been proposed. All are based on similar principles of relaying packets from the Baltzer Science Publishers BV

2 132 A. Fladenmuller, R. De Silva / The effect of Mobile IP handoffs on TCP home network to a foreign network before passing the packets to the mobile host. Routing in the opposite direction is normally assumed to take the normal routing path. Many of these alternate solutions also attempt to solve wireless networking problems. For example, I-TCP [1] uses a non-standard Mobile IP implementation developed at Columbia University to solve mobile routing and at the same time uses two separate TCP links to provide different services for varying wireless and fixed environments. A different solution for handling mobile routing is Snoop [2] which attempts to use multicast addresses to hide the location of mobile computer. 4. Study of the effects of the mobile routing handoffs When the mobile computer moves into a new network region, mobile routing services will have to change to reflect this. These changes generally require an exchange of packets called a handoff and during this period, normal transmissions to the mobile host are disrupted. We are interested in the effects of mobile routing handoffs on transport protocols. Handoffs take place at two levels. The first is the lowlevel handoff that involves the mobile host moving to a new network. In terms of a fixed network, this may consist of plugging the mobile computer onto the network while in a wireless network environment it may simply consist of moving into a new cell. The second level involves the mobile routing handoff, which detects that the mobile host has moved into a new network area and handles changes to redirect traffic to the mobile host. We are focusing our investigation on that type of handoff. reliable by acknowledging regurlaly each group of received packets. The different steps of the handoff are shown in figures 2 and 3. The first step occurs when the mobile host receives a signal advertising the new foreign agent. The mobile host then answers by sending an identification message to this foreign agent (step 2) which then registers to the home agent (step 3). The handoff is completed as shown in figure 3 when the home agent authorises the registration (step 4) of the mobile host. Figure 2 shows that when a handoff occurs, data can be lost. During long handoffs the acknowledgments from the mobile host will not get to the corresponding host. The corresponding host will therefore consider these unacknowledged packets to be lost and continually retransmit the last lost packet untill it gets acknowledged. This would not affect the transmission if the TCP congestion control algorithm was not misinterpreting the loss of data as a congestion problem. In fact, a slow handoff can have two direct negative effects on the TCP performances. Firstly in TCP [6], each packet has to be acknowledged to guarantee the reliability. If after a certain time (RTO: Retransmission TimeOut value is approximately 3 roundtrip time) the acknowledgment has not been received, the packet is retransmitted. To prevent network congestion, the timeout value is doubled for each unsuccessful retransmission. This behaviour is called the exponential backoff. After the disconnection, it is necessary for a data packet to be correctly received to resuscitate the connection. Due to successive timeouts occurring during the handoff period, the exponential backoff algorithm results in long delays before retransmitting a data packet. Therefore after the registra The potential effects on a TCP transmission Figures 1, 2, 3 show the different interactions occurring during a handhoff phase and show they can affect a TCP transmission. In this example, the corresponding host is sending data to the mobile host. As expected by the Mobile IP protocol, data is transmitted to the home agent, then to a foreign agent which forwards it to the mobile host. This is shown in figure 1. The TCP transmission is made Figure 2. Handoff between 2 foreign networks. Figure 1. Before the handoff. Figure 3. After the handoff.

3 A. Fladenmuller, R. De Silva / The effect of Mobile IP handoffs on TCP 133 tion, there can be a period of no activity until a retransmission occurs. Secondly, the slow start algorithm has been designed to prevent TCP from transmitting its full window size when the underlying network is congested. It is based on the assumption that if a packet is lost during transmission, it is due to congestion and as a result TCP immediatly reduces its current window size. A long handoff time therefore results in a small window size immediately after the link is resuscitated. So it takes more time to reach a throughput similar to the one before the handoff. To illustrate this phenomenon we have shown in figure 2 a window size of n for the TCP transmission (packets sent ranging from number i + n to i + 2n), whereas in figure 3 the window size is only of 1 packet Possible solution One simple solution to avoid packets getting lost during the handoff would be to modify slightly mobile IP and allow data packets to be stored at the foreign agent. Thus when a handoff occurs, the old foreign agent would forward all the stored packets to the new foreign agent. If this happens fast enough, such a mechanism would prevent the triggering of the TCP congestion control mechanisms. This solution is simple to implement and seems reasonable for two reasons. Firstly, the amount of data stored would be limited. Because of the TCP windowing system all the acknowledged packets could be removed from the buffer. As the number of non-acknowledged packets is limited by the TCP window size, it would be easy to bound the buffer size at the foreign agent. Secondly, the two foreign agents would be close to each other otherwise the disconnection would be so long that looking for an improvement of performances would not make sense. Thus, transferring the data packets between the two close foreign agents should be faster than retransmitting them from the remote corresponding host. Nevertheless, such a solution could have a real positive effect only if it can prevent the retransmission of lost packets. The calculation of the TCP retransmission timer (RTO) is based on the roundtrip time of the connection, and its value depends both on the link quality and the distance between the components of the model. Similarly, it is only when the handoff is completed that the TCP transmission can be resuscitated. To avoid the retransmission of data, the handoff duration should be smaller than the RTO value. As an handoff requires an exchange of several registration messages, its duration also depends on the quality of the link and the distance between the home and foreign agents. To evaluate whether it is possible to avoid a degradation in the performance of TCP transmissions, we conducted a series of experiments. In the following section, we present our measurements and comparisons of the RTO and handoff duration with different network configurations. 5. Experiments and results Figure 4. Testbed configuration. It has been shown in [3] that handoffs 1 have a negative effect on TCP performance over wireless networks. In order to determine whether this degradation of performance is due to the wireless link, we compared the effects of handoffs over wireless and fixed networks Wireless vs. fixed network handoffs Our experimental testbed consisted of a mobile host, two foreign agents and a home agent deployed in a normal office environment as shown in figure 7. The PCs (486s and Pentiums) used for these tests were running Linux (version ) and the Mobile IP v1.0 developed at the University of New York [4]. We have chosen this implementation as it complies with the IETF Mobile IP draft. Tcpdump was used to observe the data transmission during the Mobile IP handoff. The home and foreign agents and the corresponding host were all connected through fixed LANs (Ethernet 10 Mbps). The mobile host was connected to the foreign agent using wireless links (WaveLan 2 Mbps) for the first experiments and fixed networks (Ethernet 10 Mbps) for the second tests. Figure 4 presents the packets sent and the acknowledgments exchanged during the transmission between the mobile and the corresponding host. For this experiment the connection between the mobile and the foreign agents was done with a wireless link. The dotted line corresponds to the registration phase occuring between the foreign and the home agent. Similarly, figure 5 represents the experiment done in a fully wired environments. In both cases, it takes about 3 seconds for the transmission to be normally reactivated although the registration phase between the home and the foreign agent takes only 0.5 seconds. This difference can easily be explained as the handoff period consists of several operations of which one is the registration. The low-level handoff during which 1 The non-standard Columbia implementation of Mobile IP was used.

4 134 A. Fladenmuller, R. De Silva / The effect of Mobile IP handoffs on TCP Figure 5. Handoff in wireless environments. the mobile host is disconnected from both networks lasts nearly 1 second for both cases. The discovery period for the mobile host to detect that it has moved into a new network can take up to a second as this is how often advertisements are sent by foreign agents. Adding the disconnection, the discovery and the registration times, we obtain a handoff period of 2 to 3 seconds for both experiments. But once the handoff is finished we can notice the transmission does not immediatly recover. This delay, of nearly one second, is the result of one of the TCP s congestion control mechanisms: the exponential backoff. Furthermore on both graphs a curve can be observed that shows that the throughput progressively increases after the handoff. This is due to the slow start algorithms explained in the previous section. As a conclusion of these experiments, we have shown that the use of a wireless link does not increase the handoff time. However, if one of the Mobile IP registration messages is lost due to the poor link quality 2 then the handoff for a wireless link might be longer. The only difference between the experimental results shown is the throughput of the transmission. An important issue to raise is the poor performances of TCP. One third of the disconnection of the transmission is due to the unsuitable congestion control algorithm of TCP. Both the slow start and the exponential backoff mechanisms are triggered because the handoff duration is greater than the RTO timer. As the experiments were conducted in a LAN, the foreign and home agents were close to each other so the experimental conditions are ideal to obtain the faster handoff. The only possibility would be to check what happens if the RTO increases. We have therefore conducted the same experiments in wide area networks Local vs. distant network handoffs We have conducted similar expirements as in section 5.1, but we have chosen a remote corresponding host in order to increase the roundtrip time of the transmission. Hence 2 This occurred only once during our experiments. Figure 6. Handoff in wired environments. Figure 7. Handoff when transmitting in a WAN. we expect the timeout value to be greater than the handoff duration and thus to avoid TCP s slow start. For our experiments, the corresponding host was in France while the rest of the computers remained in Australia. The results obtained in figure 6 show that the throughput is 100 times lower than the one obtained in figure 5. In this configuration, we had a timeout time of roughly 1.5 seconds, whereas the handoff period remained at 3 seconds. Since the timeout value remained much smaller than the handoff period it was not possible to avoid the slow start. We believe that our choice of network configuration is about the worst that can be achieved currently on the Internet. This suggests that it may not be possible to avoid slow start during a Mobile IP handoff in any realistic network Other observations The routers in our local network are optimised for use with static routes. They map the IP address to the physical address, which gives faster mapping and redirection of data packets. However when computers are mobile this causes problems. The packets are still sent on the home LAN but with a mac address destination rather than the IP one. The home agent is looking for packets with the IP

5 A. Fladenmuller, R. De Silva / The effect of Mobile IP handoffs on TCP 135 address destination of the mobile host to forward them to the new network, but as the mac and IP address do not correspond, the packets get lost in the home LAN. This constitutes a major drawback for users mobility and this problem should be taken into account by the router constructors and/or the standardisation groups designing mobile protocols. 6. Conclusion The experiments presented in section 4 have shown the negative effects of handoff and TCP s congestion control mechanisms. The slow start algorithm cannot be avoided without some modification to either TCP or Mobile IP. Buffering packets at the foreign or home agent appears to be a good solution to reduce loss during handoff. However it cannot prevent timeouts from occurring and triggering the slow start algorithm. We have shown that Mobile IP handoffs negatively affect transmission, we must consider how this influences current applications. Although a handoff might cause a performance drop, it will probably not adversely affect applications like FTP and Telnet. Most real-time applications are based on UDP and hence are designed to handle loss of packets that would occur when a handoff takes place. Although current applications may not be adversely affected by Mobile IP handoffs, the problem is likely to become more significant in the future. As users become more mobile, the frequency of handoffs will increase. In a picocell environment, if handoff takes too long, users may reach to the next cell before completing the handoff. Therefore it will be necessary in the future to improve handoff performances which will require the modification of both Mobile IP and TCP. Acknowledgements This work was completed while the authors worked at UTS and they would like to thank the university for its financial support. References [1] A. Bakbe and B. Badbinath, I-TCP: Indirect TCP for mobile hosts, in: Proc. of 15th Int. Conf. on Distributed Computing Systems (May 1995). [2] H. Balakrishnan, S. Seshan, E. Amib and R. Kratz, Improving TCP/IP performance over wireless networks, in: Proc. of 1st Int. ACM Conf. on Mobile Computing and Networking (MOBICOM) (November 1995). [3] R. Caceres and L. Iftode, Improving the performance of reliable transport protocols in mobile computing environments, JSAC, Special Issue on Mobile Computing Networks (1994). [4] A. Dixit and V. Gutta, Mobile IP for Linux (ver 1.00), Tech. rep., Dept. of Computer Science, State University of New York (1996). [5] Internet draft, IP mobility support, Tech. rep., Internet Engineering Task Force (April 1996). [6] W.R. Stevens, TCI/IP Illustrated, Vol. 1 (Addison Wesley, 1994). Anne Fladenmuller completed her Ph.D. at the University of Paris 6, France, in 1996 on QoS issues. She then worked at the University of Technology, Sydney, where she obtained a lecturer s position. She joined the Alcatel research center in Her current research interests are QoS, mobility, adaptive applications and protocols. Anne.Fladenmuller@alcatel.fr Ranil De Silva completed his Ph.D. at the University of Technology, Sydney, in August He received his BCompSci (Hons) from Bond University, Gold Coast, in His research focused on the development of protocols that could be dynamically tailored to changing environments. He is currently employed by Cisco Systems Australia. rdesilva@cisco.com