Internet Engineering Task Force S. Bahk INTERNET DRAFT J. Kim Seoul National University H. Kim Ajou University 10 Apr. 2001 Spurring TCP retransmission upon wireless uplink losses draft-bahk-pilc-tcp-wireless-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Comments should be submitted to the PILC mailing list at pilc@grc.nasa.gov. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract In this informational draft, a simple TCP-level method to tackle unnecessarily inflated TCP retransmission timeout (RTO) value due to non-congestion losses over wireless uplink is evaluated. This method works between the handset and the intermediate node, and does not require the changes on legacy TCP implementations on wireline side. It uses one bit, named Kick (K) bit, from the TCP header to signal the handset or IN to override RTO. Also, this method does not undermine the congestion-control aspect of RTO exponential backoff. Expires 10 Oct. 2001 [Page 1] INTERNET DRAFT Spurring TCP upon wireless uplink losses Apr. 2001 Simulations show that kicking TCP connections out of long RTO backoff induced by wireless losses reduces TCP response time significantly. The performance improvement is more pronounced under larger data sizes and worse channel quality. 1 Introduction TCP traditionally assumes that segment losses are congestion losses, but on wireless link losses are caused by shadowing, multipath fading, high bit error rate (BER) and handoff. TCP can erroneously react by exponentially reducing the congestion window size, which leads to TCP throughput degradation. Prior research shows that the effect can be mitigated by splitting the TCP connection[ITCP], by making link layer TCP aware[SNOOP], by making the TCP sender not react to non-congestion losses[ELN], or by freezing TCP during bad channel state [FREEZETCP]. However, a related problem little addressed so far is TCP retransmission timeout (RTO) backoff. In TCP, repeated losses of the same segment force the RTO to be exponentially inflated. In other words, the gap between the successive retransmission attempts doubles every backoff. In wireless environment, packet transmissions during elongated loss periods will be lost, and successively failed retransmissions will have inflated the RTO to a very high value by the time the wireless channel returns to good state. Then even if the wireless link is usable again, TCP sender could wait long until the next retransmission timer expiration. We propose a method to avoid large response times for TCP data transfers, due to unnecessarily inflated TCP RTO value induced by non-congestion losses on wireless link. In particular, we narrow our focus on _uplink_ losses in this draft. We require changes on mobile host (MH) TCP/IP and minimal support from an intermediate node (IN) on the TCP path. But we do not require any change of legacy TCP implementations on the wireline side so that this approach is amenable to deployment. 2 Spurring TCP over wireless uplink Although MHs are expected to function as clients for most applications, there are a group of applications where both MH and the wireline node take on peer's role. telnet is a representative example. Albeit infrequent, data upload using such as ftp will still remain. And interactive applications such as real-time chat, network Expires 10 Oct. 2001 [Page 2] INTERNET DRAFT Spurring TCP upon wireless uplink losses Apr. 2001 game, or whiteboard, can also use TCP. All proposed TCP improvements so far, however, focus on guarding TCP throughput against downlink wireless losses only. In this draft, we evaluate a mean-and-lean TCP- level ``kicking" mechanism, which forces a TCP connection dormant in a large RTO backoff to immediately resume transmission as soon as the wireless uplink outage is over. This solution does not require any new ICMP message type, interlayer signaling, or channel state monitoring on physical layer as in Karn[KICKTCP]. Rather, ``kicking" in our scheme is simply manifest in the form of an early retransmission, done earlier than the retransmission timer suggests. Also in the same vein, we do not require the datalink layer retransmission support as in [RLP]. Also for feasibility, we do not require changes on legacy TCP implementations on wireline side[FREEZETCP]. For instance, we avoid requiring wireline side TCP to bound RTO to a small value or to change the backoff ratio to less than 2 [SHORTRTO]. Furthermore, modifying RTO backoff itself is undesirable since it potentially undermines its role as a congestion control measure. To avoid interfering with congestion control aspect of the RTO backoff, kicking is done independently of the retransmission based on RTO values. Moreover, we limit the kicking to between IN and MH, since the kicking traffic spilled into the wireline network may worsen the congestion. Namely, if the congestion is inside the wireline network not on the wireless link, data transmission earlier than RTO suggests will defeat the congestion control purpose of RTO backoff. Monitoring the wireless link and freezing the wireline TCP sender before the wireless link using zero window advertisement is shown to boost downlink throughput [FREEZETCP], but it may be difficult to warn the sender fast enough in face of fast to moderate fading situation. Also, fast change in the channel state may render the congestion window backoff due to triplicate ACK[TRIPLICATEACK] too frequent. So we retain the reactive approach, where the retransmission is allowed to happen, but the impact on the RTO by those induced by wireless losses are quickly resolved. We use one bit among the 6 reserved bits in the TCP header. We call this bit the ``K (kick) bit", and we require MH's TCP and IN be aware of the bit and take appropriate actions when they see it. With the K bit set, a ``kick segment" is simply the data segment that has been scheduled to be retransmitted by the retransmission timer. In case the kick TCP segments are leaked into the global Internet, it may adversely affect the congestion. So the IP layer of MH may be modified to set TTL to a small value so that the kick segments do not go beyond the wireless network backbone, even in case IN is not kick- aware. In order to override the retransmission timer and attempt an early retransmission (i.e. kick), we run a new timer in MH TCP, called the ``kick timer". The basic idea here is to start the kick Expires 10 Oct. 2001 [Page 3] INTERNET DRAFT Spurring TCP upon wireless uplink losses Apr. 2001 timer whenever the retransmission timer is started, but expire it earlier than the retransmission timer when RTO becomes too large. When MH's TCP transmits data towards the wireline network, the kick timer is set or reset whenever the retransmission timer is set or reset, respectively. When the kick timer expires before the retransmit timer does, MH transmits a kick segment. When the kick- aware IN receives a kick segment, it checks if it already forwarded the segment to the global Internet. For this purpose, IN is required to remember the largest sequence number for each TCP connection from a MH. If IN did forward, it sends an ACK for the segment with the K bit set (a ``kick-back"). If it did not, it forwards the segment after resetting the kick flag and TTL (if necessary), and sends a kickback to MH for the segment. Upon receiving a kickback, MH stops the kick timer, suppressing further kicks. This is because MH has been assured by the kickback that the segment was delivered to IN. In case the segment is lost further down the path (i.e. on wireline portion of the connection), normal congestion control rather than the wireless retransmission mechanism (i.e. kick) should react to it. Note that the kickback should NOT be considered a normal ACK, and it should be discarded after stopping the kick timer. This is not to break the end-to-end semantics of the TCP connection. Finally, as to the wireline side transmitting data towards MH, existing proposals such as using an intermediate node[SNOOP] or an end-to-end approach[FREEZETCP] can be used. 3 Simulation In our simulation using ns-2, the physical channel state is modeled by a continuous time 2-state Markov chain[2STATE]. A single TCP Reno connection is run between a wireline side host and a MH (which will be a typical case in reality), where the host functions as the intermediate node as well. The kick timer interval is set to the connection RTT, which upper bounds the airlink RTT. (In this simulation the two RTTs are equivalent). The wireless bandwidth is set to 64Kb/s. The link delay is set to 10ms. The TCP segment size was set to 536 bytes, making a packet time to be 0.0067 seconds. The buffer in the router has 32 slots, much larger than the bandwidth- delay product of the network. We vary the file size up to 50KB. These small file sizes fit in with our model where small uploads and interactive traffic are assumed to be dominant. -------------------------------------------------------------------- moderate fading | 10KB 20KB 30KB 40KB 50KB -------------------------------------------------------------------- TCP, avg | 1.524 3.940 6.421 8.911 12.100 TCP, 95% | 3.000 8.331 12.689 29.660 30.916 -------------------------------------------------------------------- Expires 10 Oct. 2001 [Page 4] INTERNET DRAFT Spurring TCP upon wireless uplink losses Apr. 2001 Kick, avg | 1.634 3.934 5.712 8.618 10.995 Kick, 95% | 2.959 8.097 10.904 17.225 19.410 -------------------------------------------------------------------- Table 1. Average and 95 percentile response times, moderate fading Table 1 shows the average and 95 percentile response times of vanilla TCP and Kick TCP, respectively, when we vary the data size to be transported from 10KB to 50KB. The numbers are obtained from 100 simulation runs for each data size. We set the average good and bad intervals to 0.8 and 0.2 seconds (i.e. a moderate fading), respectively [2STATE]. The average good interval can allow for approximately 10 segment transmissions, taking account of TCP/IP and link layer header such as PPP. The 95th percentile response time of TCP is very high and unstable, and the time difference from the Kick TCP gets larger with data size. -------------------------------------------------------------------- fast fading | 10KB 20KB 30KB 40KB 50KB -------------------------------------------------------------------- TCP, avg | 2.867 7.014 13.353 20.609 29.694 TCP, 95% | 33.916 54.756 129.551 75.567 168.706 -------------------------------------------------------------------- Kick, avg | 2.525 5.889 8.986 12.649 16.395 Kick, 95% | 6.505 17.239 19.760 31.705 40.047 -------------------------------------------------------------------- Table 2. Average and 95 percentile response times, fast fading Table 2 shows the average and 95 percentile response times (in seconds) of vanilla TCP and Kick TCP with fast fading. The average good and bad intervals are set to 0.08 and 0.02 seconds. The average good state interval is barely enough to accommodate one packet transmission. As expected, response times are much worse than the moderate fading case, and the performance difference between the vanilla TCP and Kick TCP is evident even in small data transfers. In the table, TCP is shown to have extremely large response times in general. In contrast, Kick TCP remains smaller and more stable. -------------------------------------------------------------------- slow fading | 10KB 20KB 30KB 40KB 50KB -------------------------------------------------------------------- TCP, avg | 1.309 2.582 3.788 8.811 10.688 TCP, 95% | 2.859 7.131 16.438 24.035 31.561 -------------------------------------------------------------------- Kick, avg | 1.309 2.582 3.788 8.911 10.688 Kick, 95% | 2.159 6.206 8.337 14.611 21.545 -------------------------------------------------------------------- Expires 10 Oct. 2001 [Page 5] INTERNET DRAFT Spurring TCP upon wireless uplink losses Apr. 2001 Table 3. Average and 95 percentile response times, slow fading Table 3 is the 95th percentile and average response times under slow fading. The good and bad intervals were set to 8 and 2 seconds. A noticeable change from earlier tables is that the average response times are almost identical. This is because the good channel state persists long enough to transmit the entire files. But as for 95 percentile response times, Kick TCP is 1.5 to 2 times better as data size gets larger. 4 Conclusion In summary, we presented and evaluated a mean-and-lean TCP-level scheme to reduce the response time under wireless uplink losses. In spirit, the evaluated scheme is a transport-level equivalent of the traditional datalink-level retransmission timer mechanisms. However, the merit of the evaluated scheme is that it is simpler to implement on mobile host's TCP. For instance, it does not require coordination with any other protocol layers. And the modification needed for mobile host TCP code is about 5 additional lines in the ns execution path. We expect similar complexity in real TCP codes. The intermediate node modification is also minimal, compared with existing schemes[SNOOP,ELN]. When SNOOP-like techniques are used for downlink performance boosting, the Kick TCP scheme can exploit the intermediate node's capability to enable kicking, without incurring too much additional overhead. The Kick TCP scheme significantly improves the TCP response time especially under fast fading, a difficult condition for TCP connection crossing a wireless hop. Although relatively smaller, we observe consistent performance improvement in moderate and slow fading conditions as well. References [2STATE] A. A. Abouzeid, S. Roy, and M. Azizoglu, ``Stochastic Modeling of TCP over Lossy Links," Proceedings of Infocom 2000. [ELN] H Balakrishnan, V. Padmanabhan, S. Seshan, and R. H. Katz. A Comparison of Mechanisms for Improving TCP Performance over Wireless Links. IEEE/ACM Transactions on Networking, 5(6):756ff, 1997. [FREEZETCP] T. Goff , J. Moronski, D. S. Phatak, and V. Gupta, ``Freeze-TCP: A true end-to-end enhancement mechanism for mobile environments," in INFOCOM, (Israel), 2000. [IS707] TIA/EIA/IS--707, "Data services option standard for wideband spread spectrum digital cellular system," Feb. 1998. Expires 10 Oct. 2001 [Page 6] INTERNET DRAFT Spurring TCP upon wireless uplink losses Apr. 2001 [ITCP] Bakre A., and Badrinath B.R. I-TCP: Indirect TCP for Mobile Hosts. In: Proc. of the 15th International Conference on Distributed Computing Systems (ICDCS), Vancouver, British Columbia, Canada, May 1995. [KICKTCP] Phil Karn, ``Kicking TCP," a contribution to PILC mailing list, March 2000. Available at http://pilc.grc.nasa.gov/pilc/list/archive/0690.html. [SHORTRTO] Y. Bai et al., ``TCP/RLP Coordination and Interprotocol Signaling for Wireless Internet," Proceedings of Vehicular Technology Conference Spring, 1999. [SNOOP] H. Balakrishnan et al., ``Improving TCP/IP Performance over Wireless Networks," Proc. 1st ACM Conf. on Mobile Computing and Networking, Berkeley, CA, Nov. 1995. [TCPPROBING] V. Tsaoussidis and H. Badr, ``TCP-Probing: Towards an Error Control Schema with Energy and Throughput Performance Gains," Proceedings of ICNP 2000. [TRIPLICATEACK] R. Caceres and L. Iftode, ``Improving the Performance of Reliable Transport Protocols in Mobile Computing Environments," IEEE JSAC Special Issue on Mobile Computing Network, 1994. [WTCP] K. Ratnam and I. Matta. WTCP: An Efficient Mechanism for Improving TCP Performance over Wireless Links. In Proc. Third IEEE Symposium on Computer and Communications (ISCC '98), June 1998. Code available from http://www.cs.bu.edu/faculty/matta/software.html. Authors' Address Saewoong Bahk Seoul National University New Media Laboratory Sinlim-dong San 56-1, Kwanak-gu Seoul 151-742, Korea Phone: +82-2-880-8414 EMail: sbahk@netlab.snu.ac.kr Jin-Ho Kim Seoul National University New Media Laboratory Sinlim-dong San 56-1, Kwanak-gu Seoul 151-742, Korea Expires 10 Oct. 2001 [Page 7] INTERNET DRAFT Spurring TCP upon wireless uplink losses Apr. 2001 Phone: +82-2-880-8434 EMail: jhkim@netlab.snu.ac.kr Hyogon Kim Ajou University 7F Daewoo Foundation Building Namdaemoon-ro 5-ga, Joong-gu Seoul 100-095, Korea Phone: +82-2-319-4080 EMail: hyogon@madang.ajou.ac.kr Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires 10 Oct. 2001 [Page 8]