Internet DRAFT - draft-bahk-pilc-tcp-wireless
draft-bahk-pilc-tcp-wireless
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]
