for a wide range of hand-off periods. We compare TCP. Tahoe and Reno with TCP Probing under various scenarios of hand-off duration, propagation delay and ...
Behavior of TCP-Probing with Hand-offs A. Lahanas and V. Tsaoussidis College of Computer Science Northeastern University Boston, MA 02115
Abstract: Performance of standard TCP is signifi-
ied the performance of TCP over wireless links with fading channels and found that most of the TCP implementations (Tahoe, Reno and New-Reno) have similar energy and throughput performance with the exception of high error rates where Tahoe yields better results. In general he observed that time-outs are extended during the hand-off process or when the link is fading.
cantly degraded during hand-off periods of mobile communications. We show here that carefully designed probing mechanisms can cancel this incompetent behavior of TCP for a wide range of hand-off periods. We compare TCP Tahoe and Reno with TCP Probing under various scenarios of hand-off duration, propagation delay and mobility conditions of the user. We measure the goodput efficiency of data transfer as well as the energy efficiency of the protocols’ mechanisms in terms of overhead and time. Our results show that TCP Probing demonstrates significant gains in both energy and throughput efficiency by avoiding unnecessary timeout extensions and retransmission of data which is likely to be lost due to hand-offs.
Solutions that deal with the impact of hand-offs on TCP performance can be grouped in three categories: (i) split TCP solutions that correspond to the particularity of the network (i.e., wired/wireless), (ii) proxy solutions that require intervention at the base station and (iii) end-to-end solutions at the transport level only. A proposal of a split protocol is IndirectTCP [5]. An example of a reliable protocol in the second category is the Snoop-TCP [6]. The protocols in the two first categories need intervention at the base station and once they are deployed it is practically difficult to change or upgrade them. In addition, these solutions do not comply with the universal nature of an end-to-end protocol such as TCP which is designed to work with a variety of heterogeneous networks and devices. Protocols in the third category solve the problem by modifying the transport protocol at the end-hosts, maintaining so the end-to-end semantics of TCP. A novel approach in this category is the Freeze-TCP [7] where the transport layer can interact with all the layers below the stack. As soon as the receiver receives a signal for a potential hand-off process, TCP receiver (i.e., here the mobile host) advertises a zero window to the sender. This approach requires that the hardware detects in advance a potential hand-off and notifies the transport layer. Another approach in the same category is TCP-Probing [8]. The core mechanism of this protocol is the Probing Cycle which is initiated every time the sender experiences
1 Introduction TCP is fine-tuned for wired networks where link errors and mobile-specific operations is not a concern. Missing packets or lack of acknowledgments by the receiver is interpreted as congestion and TCP applies congestion control algorithms [1]. In mobile computing where networks consist of wireless cells and users might move between the cells, TCP experiences delays due to hand-offs. The connection goes idle as long as the mobile host and the Base Station are involved in Mobile IP Routing [2]. This delay is interpreted as congestion by TCP and as a consequence its performance is degraded significantly. The performance of TCP in mobile computing environments has been studied thoroughly by several researchers. Caceres and Iftode [3] have studied the impact of hand-offs on TCP and in order to improve its performance they proposed a three DACK reply from the mobile host to the TCP sender immediately after the hand-off termination. Zorzi and Rao [4] have stud1
data loss. During the probing cycle zero-byte data (probing) packets are send and acknowledged by the end hosts. Probing packets will be lost while hand-off process continues, however a successful completion of the probing cycle signals an error free channel to the transport layer. A brief description of the TCP-Probing is given in Section 2. In this work we investigate the performance of TCPProbing in a mobile environment with varying handoff periods and we compare it with the standard TCP: Tahoe and Reno. The conclusions on the performance of Tahoe and Reno are supported by the results shown in [3]. The comparison with TCP-Probing highlights that probing mechanisms improves significantly the performance of standard TCP. More precisely, our results show that both communication time and retransmission overhead of TCP-Probing are relatively smaller than that of Tahoe and Reno.
2
lows Reno to reduce the CWND value to half. After the Fast Recovery Reno uses congestion avoidance to probe for extra bandwidth. TCP-Probing is introduced in [8]. In addition to Reno’s mechanisms, TCP-Probing has two new mechanisms: (i) Probing Cycle [11] and (ii) Immediate Recovery (IR). This protocol is intended for heterogeneous networks where wireless components induce bit error rates (BER) that are higher than in wired networks. The probing cycle is a simple mechanism designed to detect error-free links and available bandwidth. Every time TCP experiences packet loss (timeout or 3-DACK) it suspends data transmission and will send (once per RTT) a TCP header without payload and wait for an acknowledgment of this header. This enables the sender to efficiently monitor the network on an end-to-end basis. Loss of probing headers due to BER or hand-offs will not cause TCP time-out extension. Instead, TCP-Probing continues the probing cycle. The probe cycle terminates when network conditions have improved sufficiently that the sender can make two successive round-trip-time (RTT) measurements from the network, at which point it will have more information on which to base its errorcorrection response than does “standard” TCP. In the event that persistent error conditions are detected, the sender backs off by adjusting the congestion window and threshold downwards as would standard TCP. On the other hand, if the conditions detected indicate only a transient random error that did not impact the network’s effective throughput capacity, the sender could immediately resume transmission at a level that makes appropriate use of available network bandwidth. We call this adjustment “Immediate Recovery”. For each window of data sent in the network, TCP measures a sample RTT and TCP-Probing records the best/smaller sample RTT (Best RTT). Also during the Probing Cycle TCP-Probing measures the time to complete each individual cycle. If both samples taken during the Probing Cycle are smaller than the Best RTT, TCPProbing resumes with IR: CWND is set almost to the value before the probing cycle and is increased by the CA algorithm. Otherwise TCP-Probing resumes with SS and the time-out value is extended as in the Tahoe’s algorithm [1]. Although new techniques have been proposed to improve the performance of TCP over wireless net-
Error Control Mechanisms
The protocols tested in our experiment are TCP Tahoe, Reno and TCP-Probing. TCP Tahoe is the first modification of TCP [9] and was developed at a time when Internet suffered from congestion. Tahoe’s approach implements three mechanisms: (i) Slow Start (SS), (ii) Congestion Avoidance (CA) , and (iii) Fast Retransmit (FRt) [1]. These three mechanisms provide the core algorithm of congestion control of TCP which is based on the additive-increase/multiplicative-decrease principles. TCP gets feedback on the level of congestion from the arriving ACKs. When ACKs do not arrive at the sender TCP waits for a time-out period. Note that its sending rate is always restricted by the congestion window (CWND). After a time-out or 3-DACK event, the congestion window (CWND) is set to one packet size. The Slow Start (SS) mechanism increases the CWND one packet every ACK until CWND reaches a congestion estimation value called slow start threshold. After SS, TCP probes gradually the network for available bandwidth using the Congestion Avoidance (CA) mechanism which increases the CWND by a fraction of CWND (1/CWND) for each ACK received. TCP Reno, which includes all the mechanisms of Tahoe, introduces a new mechanism: Fast Recovery (FRc) [10]. Instead of reducing the CWND to one packet size after a 3-DACK event, Fast Recovery al2
works the experiments conducted in [4, 12] show that they often fail to perform well. In addition, in [12] is shown that the older versions of TCP perform better in heterogeneous networks, rendering them the candidates of choice for comparison with experimental versions of TCP for heterogeneous networks.
as the ratio of the total extra bytes send by the sender (including retransmitted data) over the file size (5MB). The following section describes the TCT and the overhead performance of standard TCP and TCP-Probing with hand-offs.
3
4
Testing Methodology
4.1
The three protocols (Tahoe, Reno and TCP-Probing) were tested on the x-kernel protocol framework [13]. Each session was run on two dedicated hosts connected through a 10Mbps Ethernet link and the task of the application layer was to send a 5MByte message size - sufficient enough to observe the performance of the protocol for long communication time. The hand-offs due to mobility were simulated by a virtual protocol, VHANDOFF [12], which was configured between TCP and IP. VHANDOFF consists of a two state Markov chain configured so that during one phase (ON) it discards packets and during the other phase (OFF) it simply relays the packets to the IP or TCP layer. The protocol resides at each state for an exponentially distributed amount of time with a userspecified mean duration. This way we can configure hand-offs of different frequency. The ‘ON’ phase was configured such that packets could be discarded for a portion of the residual time so that we could simulate hand-offs of different duration or rendezvous [2]. The protocols were tested with different rendezvous delays and hand-off frequency. The ‘OFF’ phase was configured to 3, 5, and 10 so that the protocol could simulate hand-offs every 3, 5, and 10 seconds respectively. The rendezvous delay was selected 0.3 and 0.5 seconds and was fixed during each session. These rendezvous delays result in 15% and 25% packet error rate (PER) respectively. Data as well as ACKs were dropped during the hand-off. VHANDOFF was also configured to add additional delay to the TCP packets in order to simulate links of variable propagation delay. For each configuration we measured the time it took the transport protocol to transmit the application message as well as the extra number of bytes (overhead) transmitted for reliable transmission. We present these measurements in the figures below as Task Completion Time (TCT) and Overhead. The overhead is defined
The Hand-off Effect Effect on Transmission Time
Figures 1,2,3,4, 5, and 6 display the transmission time of protocols on wireless networks with hand-offs of different frequency and duration. It can be seen in the graphs that the performance of protocols that experience frequent hand-offs is deteriorated. For example, Figure 1 shows that the protocols that experienced hand-off every 10 seconds take less than 30 seconds to transmit the message, whereas the same protocols when experience hand-off every 3 seconds (Figure 3) increase their transmission time significantly. 30 Tahoe Reno TCP-Probing
Time (sec)
20
10
0 20
40
60
80
100
120
RTT (ms)
Figure 1: 0.3 sec. rendezvous and hand-off every 10 sec. 60
Tahoe Reno TCP-Probing
Time (sec)
40
20
0 20
40
60
80
100
120
RTT (ms)
Figure 2: 0.3 sec. rendezvous and hand-off every 5 sec. 3
During the hand-off process data packets or acknowledgments will be lost. This will cause the TCP sender to wait until the time-out value expires. The time-out event is considered as an indication of congestion by TCP (Tahoe, Reno) which in turn reduce exponentially the congestion window and extend the time-out value. The hand-off effects on TCP’s performance are studied in [3] and the reader might refer to that work for more details. For hand-offs with long rendezvous (e.g. 0.5 sec.) TCP might experience two or more time-outs (depending on the granularity of the timer); this might be extended to more than 1 sec. Caceres and Iftode in their experiments [3] report that for 1 sec. rendezvous TCP might extend the time-out up to 3 seconds. In conclusion, the standard TCP experiences a three-fold problem during and after hand-offs: (i) the congestion window is shrunk consecutively resulting in the minimum window size, (ii) time-out is extended and the opportunities to rapidly detect improved bandwidth are wasted, and (iii) the protocol overhead is increased due to retransmissions while hand-off continues.
Time (sec)
30
Tahoe Reno TCP-Probing
20
10
0 20
40
60
80
100
120
RTT (ms)
Figure 4: 0.5 sec. rendezvous and hand-off every 10 sec. immediately the congestion window and the time-out value. This is an enhancement over the standard TCP mechanisms which lacks the ability to distinguish the nature of the error. 100
Time (sec)
80
Tahoe Reno TCP-Probing
60
40 Tahoe Reno TCP-Probing
20
100
Time (sec)
0 20
40
60
80
100
120
RTT (ms)
Figure 5: 0.5 sec. rendezvous and hand-off every 5 sec.
50
0 20
40
60
80
100
120
300
RTT (ms)
Time (sec)
Figure 3: 0.3 sec. rendezvous and hand-off every 3 sec. TCP-Probing, which tackles the above problems of standard TCP by using the Probing Cycle mechanism, has relatively better performance. The reasons of the improved performance are three: (i) the probing cycle in case of a hand-off event will detect the exact duration of it and will suspend TCP from sending data while hand-off process goes on; (ii) the time-out and the congestion window value are not changed for as long as the probing cycle continues; (iii) upon termination of the probing cycle, if the nature of the error is deemed to be random TCP-Probing resumes retransmission from the point before the error, adjusting
Tahoe Reno TCP-Probing
200
100
0 20
40
60
80
100
120
RTT (ms)
Figure 6: 0.5 sec. rendezvous and hand-off every 3 sec. Figures 4, 5, and 6 present the performance of the protocols with hand-offs of 0.5 second. It can be seen that TCP Tahoe and Reno increase more than linearly their transmission time in proportion to the RTT and 4
hand-off frequency. It can be seen from Figure 6 that the transmission time of TCP doubles (67s for Tahoe) or quatriples (134s for Reno) when compared to TCPProbing (34s) at 20ms RTT. The transmission time of TCP-Probing increases smoothly as the RTT and the hand-off frequency increases. For example in Figure 6 the transmission time of TCP-Probing with 20ms RTT is 34s whereas with 120ms RTT the time quatriples (120s). On the contrary, TCP Tahoe at 120s RTT needs five more times (322s) to transmit the same message than it needs at 20ms RTT (67s).
Congestion Window
60000
since the error was considered to be transient. This confirmed our expectation that TCP-Probing would “skip” the hand-off phase without extending the timeout and without adjusting the window downward. At the 14th second another time-out happened for TCPProbing. It can be seen that after the time-out it executes a TCP-like recovery - Slow Start. The sample times taken during the probing cycle were no smaller than the best RTT and the nature of the error was considered congestion. This indicates a potential improvement of the recovery decision of TCP-Probing. Figures 1,2,3, and figures 4,5,6 present the performance of the protocols for rendezvous delay of 0.3 and 0.5 second respectively. It can be noticed from these figures that the increase of the rendezvous delay deteriorates the performance of the protocol. Figure 3 shows that the TCT of Reno is 123 sec (RTT 120ms), whereas for rendezvous delay of 1 second its TCT is 335 sec. Tahoe and TCP-Probing have similar increase in their TCT. Although all the rendezvous delay is quite high the figures show that standard TCP doesn’t take advantage of error free channel. For the same RTT value its TCT triples. On the contrary the TCP-Probing will take advantage of the error free link and will exploit the available bandwidth. It can be seen from the figures that the increased rendezvous delay has less negative impact on TCP-Probing TCT (TCT doubles) than in standard TCP (where TCT triples).
Tahoe Reno TCP-Probing
40000
20000
0
5000000
10000000
15000000
20000000
25000000
Task Completion Time (ms)
Figure 7: Congestion window trace during a 5MByte transfer. In Figure 7 we plot traces of the congestion window of protocols as a function of time. The hand-off process was deterministic for all traces (aiming in reproducing the same events). It can be seen that after 5 seconds a time-out event occurs. After the time-out expires the TCP retransmits one packet (in SS) which is never acknowledged. As a sequence the time-out is backed-off and they retransmit after 2 seconds (7.5 second). TCP Reno that transmits before the hand-off has completed, experiences another time-out (three in total) and resumes retransmission at the 12th second. TCP Tahoe transmitted immediately after the hand-off process, however, after two time-outs the congestion window was set to one segment and is increased afterwards with the CA algorithm. Handoff-free transmission opportunities were lost for both Tahoe and Reno. TCP-Probing after the first time-out paused the data transmission and entered in probing cycle. Before the 7th second it detected the hand off termination and resumed transmission with Immediate Recovery. The congestion window was adjusted upward immediately
4.2
Effect on Overhead
Overhead is an indirect metric of the protocol’s performance. It shows the number of retransmissions of the protocol for reliable service. Overhead reduction is crucial in wireless networks from the fact that some of the devices are battery powered. Applying congestion avoidance techniques for overhead reduction might not be beneficiary. Indeed, sending data while the handoff process goes on will result in an increase of overhead. From the traces of Figure 7 can be seen that after 4.5 seconds Reno experiences three time-outs two of which resulted in retransmission during the handoff process. These forceful retransmissions could have been avoided if the protocol had a mechanism to detect the hand-off continuation. The overhead of the TCP is increased mainly for two reasons: (i) longer communication time, and (ii) transmissions during link fail5
ure or congestion. As explained in the section above the extended time-out and the downward adjustment of the congestion window extend the Task Completion Time. This implies also that standard TCP might increase its overhead when errors are due to hand-offs.
cause of continuing hand-off process. Reno, which experiences three time-outs, has lost two packets after each retransmission. Although standard TCP backsoff, overhead is increased. 6
3.0
Overhead (%)
5
Overhead (%)
2.5
2.0
Tahoe Reno TCP-Probing
4
3
Tahoe Reno TCP-Probing
1.5
2 20
40
60
80
100
120
RTT (ms)
1.0 20
40
60
80
100
120
Figure 10: 0.3 sec. rendezvous and hand-off every 3 seconds.
RTT (ms)
Figure 8: 0.3 sec. rendezvous and hand-off every 10 seconds.
3.0
4
Overhead (%)
Overhead (%)
2.5
3
2
2.0
Tahoe Reno TCP-Probing
1.5
Tahoe Reno TCP-Probing
1.0 20
40
1 20
40
60
80
100
60
80
100
120
RTT (ms)
120
RTT (ms)
Figure 11: 0.5 sec. rendezvous and hand-off every 10 sec.
Figure 9: 0.3 sec. rendezvous and hand-off every 5 seconds.
TCP-Probing avoids retransmissions by extending the probing cycle. TCP headers are sent (once per RTT) in the network while the hand-off continues; however, the overhead caused by these headers is insignificant compared to the overhead caused by TCP data packets. Avoiding data retransmissions while the hand-off process goes on reduces the overhead of the protocol and eliminates congestion window and timeout problems discussed in the previous section.
In figures 8, 9, 10, 11, 12, and 13 is plotted the average overhead of the protocols resulted from the same message transmission (5MB). The graphs show that overhead is increased in proportion to the RTT value and hand-off frequency. Higher RTT implies longer communication; hence more hand-offs are likely to occur and more in-the-flight packets will be lost during the hand-off process. The results show that the overhead of TCP-Probing is equal or smaller than the overhead of standard TCP. For rendezvous of 0.3 sec TCP-Probing has the same overhead as TCP, whereas for 0.5 sec rendezvous the overhead decreases significantly (see figures 11, 12, 13). For long rendezvous delays standard TCP might experience more than one time-out which will result in forceful (re)transmission of packets and extension of the time-out. The traces (Figure 7) show that after 4.5 seconds a hand-off happens and the TCP sender times-out. Then, Tahoe and Reno forcefully retransmit the packet which is lost be-
5
Conclusion
Our work examined the performance of TCP-Probing over wireless links and with the presence of hand-offs. The experiments show a significant improvement of TCP-Probing over standard TCP Tahoe and Reno. The “Probing device” is a real end-to-end solution that requires no network support. TCP-Probing has the capability to distinguish transient errors from congestion. 6
5
Overhead (%)
lected Areas in Communications, vol. 13, no. 5, 1995. 4
[4] A. Chockalingam, M. Zorzi, and R. Rao, “Performance of TCP on Wireless Fading Links with Memory,” in Proceedings of the IEEE ICC’98, Atlanta, GA, June 1998.
3
Tahoe Reno TCP-Probing
2 20
40
60
80
100
120
[5] A. Bakre and B. Badrinath, “Implementation and Performance Evaluation of Indirect TCP,” IEEE Transactions on Computers, vol. 46, no. 3, pp. 260–278, 1997.
RTT (ms)
Figure 12: 0.5 sec. rendezvous and hand-off every 5 sec. 7 Tahoe Reno TCP-Probing
Overhead (%)
6
[6] H. Balakrishnan et al , “Improving TCP/IP Performance over Wireless Networks,” in Proceedings of the 1st ACM Int’l Conf. On Mobile Computing and Networking (Mobicom), November 1995.
5
4
[7] T. Goff, J. Moronski, and D. Phatak, “FreezeTCP: A true end-to-end Enhancement Mechanism for Mobile Environments,” in Proceedings of the INFOCOM, (Israel), 2000, 2000.
3 20
40
60
80
100
120
RTT (ms)
Figure 13: 0.5 sec. rendezvous and hand-off every 3 sec.
[8] V. Tsaoussidis and H. Badr, “TCP-Probing: Towards an Error Control Schema with Energy and Throughput Performance Gains,” in Proceedings of the 8th IEEE Conference on Network Protocols, 2000.
Our results demonstrate the improved performance of TCP-Probing over standard TCP when frequent handoffs take place. Opportunities for error free transmissions and available bandwidth are not waisted; on the contrary, TCP-Probing takes advantage of the error free link by avoiding the unnecessary time-out extensions and effectively “skipping” the hand-off phases by suspending data transmission. This way overhead is reduced and and throughput is improved significantly.
[9] J. Postel, “Transmission Control Protocol,” RFC 793, September 1981. [10] M. Allman, V. Paxson, and W. Stevens, “TCP Congestion Control,” RFC 2581, April 1999. [11] V. Tsaoussidis, A. Lahanas, and C. Zhang, “The Wave and Probe Communication Mechanisms,” The Journal of Supercomputing, June 2001.
References [1] V. Jacobson, “Congestion Avoidance and Control,” in Proceedings of the ACM SIGCOMM ’88, August 1988.
[12] V. Tsaoussidis et al, “Energy / Throughput Tradeoffs of TCP Error Control Strategies,” in Proceedings of the 5th IEEE Symposium on Computers and Communications, ISCC, 2000.
[2] J. Ioannidis and G. Maquire, “The Design and Implementation of a Mobile Internetworking Architecture,” in Proceedings of the USENIX 1993 Winter Conference, January 1993.
[13] “The X-kernel,”, www.cs.princeton.edu/xkernel.
[3] R. Caceres and L. Iftode, “Improving the Performance of Reliable Transport Protocols in Mobile Computing Environments,” IEEE Journal on Se7
