path: root/doc/rfc/rfc3481.txt

Network Working Group                                    H. Inamura, Ed.
Request for Comments: 3481                              NTT DoCoMo, Inc.
BCP: 71                                               G. Montenegro, Ed.
Category: Best Current Practice            Sun Microsystems Laboratories
                                                                  Europe
                                                               R. Ludwig
                                                       Ericsson Research
                                                               A. Gurtov
                                                                  Sonera
                                                             F. Khafizov
                                                         Nortel Networks
                                                           February 2003


   TCP over Second (2.5G) and Third (3G) Generation Wireless Networks

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This document describes a profile for optimizing TCP to adapt so that
   it handles paths including second (2.5G) and third (3G) generation
   wireless networks.  It describes the relevant characteristics of 2.5G
   and 3G networks, and specific features of example deployments of such
   networks.  It then recommends TCP algorithm choices for nodes known
   to be starting or ending on such paths, and it also discusses open
   issues.  The configuration options recommended in this document are
   commonly found in modern TCP stacks, and are widely available
   standards-track mechanisms that the community considers safe for use
   on the general Internet.













Inamura, et al.          Best Current Practice                  [Page 1]
^L
RFC 3481                    TCP over 2.5G/3G               February 2003


Table of Contents

   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  2.5G and 3G Link Characteristics. . . . . . . . . . . . . . .   4
       2.1  Latency. . . . . . . . . . . . . . . . . . . . . . . . .   4
       2.2  Data Rates . . . . . . . . . . . . . . . . . . . . . . .   5
       2.3  Asymmetry  . . . . . . . . . . . . . . . . . . . . . . .   6
       2.4  Delay Spikes . . . . . . . . . . . . . . . . . . . . . .   6
       2.5  Packet Loss Due to Corruption. . . . . . . . . . . . . .   7
       2.6  Intersystem Handovers. . . . . . . . . . . . . . . . . .   7
       2.7  Bandwidth Oscillation. . . . . . . . . . . . . . . . . .   7
   3.  Example 2.5G and 3G Deployments . . . . . . . . . . . . . . .   8
       3.1  2.5G Technologies: GPRS, HSCSD and CDMA2000 1XRTT. . . .   8
       3.2  A 3G Technology: W-CDMA. . . . . . . . . . . . . . . . .   8
       3.3  A 3G Technology: CDMA2000 1X-EV. . . . . . . . . . . . .  10
   4.  TCP over 2.5G and 3G. . . . . . . . . . . . . . . . . . . . .  10
       4.1  Appropriate Window Size (Sender & Receiver). . . . . . .  11
       4.2  Increased Initial Window (Sender). . . . . . . . . . . .  11
       4.3  Limited Transmit (Sender). . . . . . . . . . . . . . . .  12
       4.4  IP MTU Larger than Default . . . . . . . . . . . . . . .  12
       4.5  Path MTU Discovery (Sender & Intermediate Routers) . . .  13
       4.6  Selective Acknowledgments (Sender & Receiver). . . . . .  13
       4.7  Explicit Congestion Notification (Sender, Receiver &
            Intermediate Routers). . . . . . . . . . . . . . . . . .  13
       4.8  TCP Timestamps Option (Sender & Receiver). . . . . . . .  13
       4.9  Disabling RFC 1144 TCP/IP Header Compression (Wireless
            Host)   . . . . . . . . . . . . . . . . . . . . . . . . . 15
       4.10 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16
   5.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 16
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 19
   10. Informative References . . . . . . . . . . . . . . . . . . . . 21
   11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
   12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26















Inamura, et al.          Best Current Practice                  [Page 2]
^L
RFC 3481                    TCP over 2.5G/3G               February 2003


1. Introduction

   The second generation cellular systems are commonly referred to as
   2G.  The 2G phase began in the 1990s when digital voice encoding had
   replaced analog systems (1G).  2G systems are based on various radio
   technologies including frequency-, code- and time- division multiple
   access.  Examples of 2G systems include GSM (Europe), PDC (Japan),
   and IS-95 (USA).  Data links provided by 2G systems are mostly
   circuit-switched and have transmission speeds of 10-20 kbps uplink
   and downlink.  Demand for higher data rates, instant availability and
   data volume-based charging, as well as lack of radio spectrum
   allocated for 2G led to the introduction of 2.5G (for example, GPRS
   and PDC-P) and 3G (for example, Wideband CDMA and cdma2000) systems.

   Radio technology for both Wideband CDMA (W-CDMA) (adopted, for
   example, in Europe, Japan, etc) and cdma2000 (adopted, for example,
   in US, South Korea, etc) is based on code division multiple access
   allowing for higher data rates and more efficient spectrum
   utilization than 2G systems.  3G systems provide both packet-switched
   and circuit-switched connectivity in order to address the quality of
   service requirements of conversational, interactive, streaming, and
   bulk transfer applications.  The transition to 3G is expected to be a
   gradual process.  Initially, 3G will be deployed to introduce high
   capacity and high speed access in densely populated areas.  Mobile
   users with multimode terminals will be able to utilize existing
   coverage of 2.5G systems on the rest of territory.

   Much development and deployment activity has centered around 2.5G and
   3G technologies.  Along with objectives like increased capacity for
   voice channels, a primary motivation for these is data communication,
   and, in particular, Internet access.  Accordingly, key issues are TCP
   performance and the several techniques which can be applied to
   optimize it over different wireless environments [19].

   This document proposes a profile of such techniques, (particularly
   effective for use with 2.5G and 3G wireless networks).  The
   configuration options in this document are commonly found in modern
   TCP stacks, and are widely available IETF standards-track mechanisms
   that the community has judged to be safe on the general Internet
   (that is, even in predominantly non-wireless scenarios).
   Furthermore, this document makes one set of recommendations that
   covers both 2.5G and 3G networks.  Since both generations of wireless
   technologies exhibit similar challenges to TCP performance (see
   Section 2), one common set is warranted.







Inamura, et al.          Best Current Practice                  [Page 3]
^L
RFC 3481                    TCP over 2.5G/3G               February 2003


   Two example applications of the recommendations in this document are:

   o  The WAP Forum [25] (part of the Open Mobile Alliance [26] as of
      June 2002) is an industry association that has developed standards
      for wireless information and telephony services on digital mobile
      phones.  In order to address WAP functionality for higher speed
      networks such as 2.5G and 3G networks, and to aim at convergence
      with Internet standards, the WAP Forum thoroughly revised its
      specifications.  The resultant version 2.0 [31] adopts TCP as its
      transport protocol, and recommends TCP optimization mechanisms
      closely aligned with those described in this document.

   o  I-mode [33] is a wireless Internet service deployed on handsets in
      Japan.  The newer version of i-mode runs on FOMA [34], an
      implementation of W-CDMA.  I-mode over FOMA deploys the profile of
      TCP described in this document.

   This document is structured as follows: Section 2 reviews the link
   layer characteristics of 2.5G/3G networks; Section 3 gives a brief
   overview of some representative 2.5G/3G technologies like W-CDMA,
   cdma2000 and GPRS; Section 4 recommends mechanisms and configuration
   options for TCP implementations used in 2.5G/3G networks, including a
   summary in chart form at the end of the section; finally, Section 5
   discusses some open issues.

2. 2.5G and 3G Link Characteristics

   Link layer characteristics of 2.5G/3G networks have significant
   effects on TCP performance.  In this section we present various
   aspects of link characteristics unique to the 2.5G/3G networks.

2.1 Latency

   The latency of 2.5G/3G links is high mostly due to the extensive
   processing required at the physical layer of those networks, e.g.,
   for FEC and interleaving, and due to transmission delays in the radio
   access network [58] (including link-level retransmissions).  A
   typical RTT varies between a few hundred milliseconds and one second.
   The associated radio channels suffer from difficult propagation
   environments.  Hence, powerful but complex physical layer techniques
   need to be applied to provide high capacity in a wide coverage area
   in a resource efficient way.  Hopefully, rapid improvements in all
   areas of wireless networks ranging from radio layer techniques over
   signal processing to system architecture will ultimately also lead to
   reduced delays in 3G wireless systems.






Inamura, et al.          Best Current Practice                  [Page 4]
^L
RFC 3481                    TCP over 2.5G/3G               February 2003


2.2 Data Rates

   The main incentives for transition from 2G to 2.5G to 3G are the
   increase in voice capacity and in data rates for the users.  2.5G
   systems have data rates of 10-20 kbps in uplink and 10-40 kbps in
   downlink.  Initial 3G systems are expected to have bit rates around
   64 kbps in uplink and 384 kbps in downlink.  Considering the
   resulting bandwidth-delay product (BDP) of around 1-5 KB for 2.5G and
   8-50 KB for 3G, 2.5G links can be considered LTNs (Long Thin Networks
   [19]), and 3G links approach LFNs (Long Fat Networks [2], as
   exemplified by some satellite networks [48]).  Accordingly,
   interested readers might find related and potentially relevant issues
   discussed in RFC 2488 [49].  For good TCP performance both LFNs and
   LTNs require maintaining a large enough window of outstanding data.
   For LFNs, utilizing the available network bandwidth is of particular
   concern.   LTNs need a sufficiently large window for efficient loss
   recovery.  In particular, the fast retransmit algorithm cannot be
   triggered if the window is less than four segments.  This leads to a
   lengthy recovery through retransmission timeouts.  The Limited
   Transmit algorithm RFC 3042 [10] helps avoid the deleterious effects
   of timeouts on connections with small windows.  Nevertheless, making
   full use of the SACK RFC 2018 [3] information for loss recovery in
   both LFNs and LTNs may require twice the window otherwise sufficient
   to utilize the available bandwidth.

   This document recommends only standard mechanisms suitable both for
   LTNs and LFNs, and to any network in general.  However, experimental
   mechanisms suggested in Section 5 can be targeted either for LTNs
   [19] or LFNs [48].

   Data rates are dynamic due to effects from other users and from
   mobility.  Arriving and departing users can reduce or increase the
   available bandwidth in a cell.  Increasing the distance from the base
   station decreases the link bandwidth due to reduced link quality.
   Finally, by simply moving into another cell the user can experience a
   sudden change in available bandwidth.  For example, if upon changing
   cells a connection experiences a sudden increase in available
   bandwidth, it can underutilize it, because during congestion
   avoidance TCP increases the sending rate slowly.  Changing from a
   fast to a slow cell normally is handled well by TCP due to the self-
   clocking property.  However, a sudden increase in RTT in this case
   can cause a spurious TCP timeout as described in Section 2.7.  In
   addition, a large TCP window used in the fast cell can create
   congestion resulting in overbuffering in the slow cell.







Inamura, et al.          Best Current Practice                  [Page 5]
^L
RFC 3481                    TCP over 2.5G/3G               February 2003


2.3 Asymmetry

   2.5G/3G systems may run asymmetric uplink and downlink data rates.
   The uplink data rate is limited by battery power consumption and
   complexity limitations of mobile terminals.  However, the asymmetry
   does not exceed 3-6 times, and can be tolerated by TCP without the
   need for techniques like ACK congestion control or ACK filtering
   [50].  Accordingly, this document does not include recommendations
   meant for such highly asymmetric networks.

2.4 Delay Spikes

   A delay spike is a sudden increase in the latency of the
   communication path.  2.5G/3G links are likely to experience delay
   spikes exceeding the typical RTT by several times due to the
   following reasons.

   1. A long delay spike can occur during link layer recovery from a
      link outage due to temporal loss of radio coverage, for example,
      while driving into a tunnel or within an elevator.

   2. During a handover the mobile terminal and the new base station
      must exchange messages and perform some other time-consuming
      actions before data can be transmitted in a new cell.

   3. Many wide area wireless networks provide seamless mobility by
      internally re-routing packets from the old to the new base station
      which may cause extra delay.

   4. Blocking by high-priority traffic may occur when an arriving
      circuit-switched call or higher priority data temporarily preempts
      the radio channel.  This happens because most current terminals
      are not able to handle a voice call and a data connection
      simultaneously and suspend the data connection in this case.

   5. Additionally, a scheduler in the radio network can suspend a low-
      priority data transfer to give the radio channel to higher
      priority users.

   Delay spikes can cause spurious TCP timeouts, unnecessary
   retransmissions and a multiplicative decrease in the congestion
   window size.









Inamura, et al.          Best Current Practice                  [Page 6]
^L
RFC 3481                    TCP over 2.5G/3G               February 2003


2.5 Packet Loss Due to Corruption

   Even in the face of a high probability of physical layer frame
   errors, 2.5G/3G systems have a low rate of packet losses thanks to
   link-level retransmissions.  Justification for link layer ARQ is
   discussed in [23], [22], [44].  In general, link layer ARQ and FEC
   can provide a packet service with a negligibly small probability of
   undetected errors (failures of the link CRC), and a low level of loss
   (non-delivery) for the upper layer traffic, e.g., IP.  The loss rate
   of IP packets is low due to the ARQ, but the recovery at the link
   layer appears as delay jitter to the higher layers lengthening the
   computed RTO value.

2.6 Intersystem Handovers

   In the initial phase of deployment, 3G systems will be used as a 'hot
   spot' technology in high population areas, while 2.5G systems will
   provide lower speed data service elsewhere.  This creates an
   environment where a mobile user can roam between 2.5G and 3G networks
   while keeping ongoing TCP connections.  The inter-system handover is
   likely to trigger a high delay spike (Section 2.4), and can result in
   data loss.  Additional problems arise because of context transfer,
   which is out of scope of this document, but is being addressed
   elsewhere in the IETF in activities addressing seamless mobility
   [51].

   Intersystem handovers can adversely affect ongoing TCP connections
   since features may only be negotiated at connection establishment and
   cannot be changed later.  After an intersystem handover, the network
   characteristics may be radically different, and, in fact, may be
   negatively affected by the initial configuration.  This point argues
   against premature optimization by the TCP implementation.

2.7 Bandwidth Oscillation

   Given the limited RF spectrum, satisfying the high data rate needs of
   2.5G/3G wireless systems requires dynamic resource sharing among
   concurrent data users.  Various scheduling mechanisms can be deployed
   in order to maximize resource utilization.  If multiple users wish to
   transfer large amounts of data at the same time, the scheduler may
   have to repeatedly allocate and de-allocate resources for each user.
   We refer to periodic allocation and release of high-speed channels as
   Bandwidth Oscillation.  Bandwidth Oscillation effects such as
   spurious retransmissions were identified elsewhere (e.g., [30]) as
   factors that degrade throughput.  There are research studies [52],
   [54], which show that in some cases Bandwidth Oscillation can be the
   single most important factor in reducing throughput.  For fixed TCP
   parameters the achievable throughput depends on the pattern of



Inamura, et al.          Best Current Practice                  [Page 7]
^L
RFC 3481                    TCP over 2.5G/3G               February 2003


   resource allocation.  When the frequency of resource allocation and
   de-allocation is sufficiently high, there is no throughput
   degradation.  However, increasing the frequency of resource
   allocation/de-allocation may come at the expense of increased
   signaling, and, therefore, may not be desirable.  Standards for 3G
   wireless technologies provide mechanisms that can be used to combat
   the adverse effects of Bandwidth Oscillation.  It is the consensus of
   the PILC Working Group that the best approach for avoiding adverse
   effects of Bandwidth Oscillation is proper wireless sub-network
   design [23].

3. Example 2.5G and 3G Deployments

   This section provides further details on a few example 2.5G/3G
   technologies.  The objective is not completeness, but merely to
   discuss some representative technologies and the issues that may
   arise with TCP performance.  Other documents discuss the underlying
   technologies in more detail.  For example, ARQ and FEC are discussed
   in [23], while further justification for link layer ARQ is discussed
   in [22], [44].

3.1 2.5G Technologies: GPRS, HSCSD and CDMA2000 1XRTT

   High Speed Circuit-Switched Data (HSCSD) and General Packet Radio
   Service (GPRS) are extensions of GSM providing high data rates for a
   user.  Both extensions were developed first by ETSI and later by
   3GPP.  In GSM, a user is assigned one timeslot downlink and one
   uplink.  HSCSD allocates multiple timeslots to a user creating a fast
   circuit-switched link.  GPRS is based on packet-switched technology
   that allows efficient sharing of radio resources among users and
   always-on capability.  Several terminals can share timeslots.  A GPRS
   network uses an updated base station subsystem of GSM as the access
   network; the GPRS core network includes Serving GPRS Support Nodes
   (SGSN) and Gateway GPRS Support Nodes (GGSN).  The RLC protocol
   operating between a base station controller and a terminal provides
   ARQ capability over the radio link.  The Logical Link Control (LLC)
   protocol between the SGSN and the terminal also has an ARQ capability
   utilized during handovers.

3.2 A 3G Technology: W-CDMA

   The International Telecommunication Union (ITU) has selected Wideband
   Code Division Multiple Access (W-CDMA) as one of the global telecom
   systems for the IMT-2000 3G mobile communications standard.  W-CDMA
   specifications are created in the 3rd Generation Partnership Project
   (3GPP).





Inamura, et al.          Best Current Practice                  [Page 8]
^L
RFC 3481                    TCP over 2.5G/3G               February 2003


   The link layer characteristics of the 3G network which have the
   largest effect on TCP performance over the link are error controlling
   schemes such as layer two ARQ (L2 ARQ) and FEC (forward error
   correction).

   W-CDMA uses RLC (Radio Link Control) [20], a Selective Repeat and
   sliding window ARQ.  RLC uses protocol data units (PDUs) with a 16
   bit RLC header.  The size of the PDUs may vary.  Typically, 336 bit
   PDUs are implemented [34].  This is the unit for link layer
   retransmission.  The IP packet is fragmented into PDUs for
   transmission by RLC.  (For more fragmentation discussion, see Section
   4.4.)

   In W-CDMA, one to twelve PDUs (RLC frames) constitute one FEC frame,
   the actual size of which depends on link conditions and bandwidth
   allocation.  The FEC frame is the unit of interleaving.  This
   accumulation of PDUs for FEC adds part of the latency mentioned in
   Section 2.1.

   For reliable transfer, RLC has an acknowledged mode for PDU
   retransmission.  RLC uses checkpoint ARQ [20] with "status report"
   type acknowledgments; the poll bit in the header explicitly solicits
   the peer for a status report containing the sequence number that the
   peer acknowledges.  The use of the poll bit is controlled by timers
   and by the size of available buffer space in RLC.  Also, when the
   peer detects a gap between sequence numbers in received frames, it
   can issue a status report to invoke retransmission.  RLC preserves
   the order of packet delivery.

   The maximum number of retransmissions is a configurable RLC parameter
   that is specified by RRC [39] (Radio Resource Controller) through RLC
   connection initialization.  The RRC can set the maximum number of
   retransmissions (up to a maximum of 40).  Therefore, RLC can be
   described as an ARQ that can be configured for either HIGH-
   PERSISTENCE or LOW-PERSISTENCE, not PERFECT-PERSISTENCE, according to
   the terminology in [22].

   Since the RRC manages RLC connection state, Bandwidth Oscillation
   (Section 2.7) can be eliminated by the RRC's keeping RF resource on
   an RLC connection with data in its queue.  This avoids resource de-
   allocation in the middle of transferring data.

   In summary, the link layer ARQ and FEC can provide a packet service
   with a negligibly small probability of undetected error (failure of
   the link CRC), and a low level of loss (non-delivery) for the upper
   layer traffic, i.e., IP.  Retransmission of PDUs by ARQ introduces
   latency and delay jitter to the IP flow.  This is why the transport
   layer sees the underlying W-CDMA network as a network with a



Inamura, et al.          Best Current Practice                  [Page 9]
^L
RFC 3481                    TCP over 2.5G/3G               February 2003


   relatively large BDP (Bandwidth-Delay Product) of up to 50 KB for the
   384 kbps radio bearer.

3.3 A 3G Technology: CDMA2000 1X-EV

   One of the Terrestrial Radio Interface standards for 3G wireless
   systems, proposed under the International Mobile Telecommunications-
   2000 umbrella, is cdma2000 [55].  It employs Multi-Carrier Code
   Division Multiple Access (CDMA) technology with a single-carrier RF
   bandwidth of 1.25 MHz.  cdma2000 evolved from IS-95 [56], a 2G
   standard based on CDMA technology.  The first phase of cdma2000
   utilizes a single carrier and is designed to double the voice
   capacity of existing CDMA (IS-95) networks and to support always-on
   data transmission speeds of up to 316.8 kbps.  As mentioned above,
   these enhanced capabilities are delivered by cdma2000 1XRTT.  3G
   speeds of 2 Mbps are offered by cdma2000 1X-EV.  At the physical
   layer, the standard allows transmission in 5,10,20,40 or 80 ms time
   frames.  Various orthogonal (Walsh) codes are used for channel
   identification and to achieve higher data rates.

   Radio Link Protocol Type 3 (RLP) [57] is used with a cdma2000 Traffic
   Channel to support CDMA data services.  RLP provides an octet stream
   transport service and is unaware of higher layer framing.  There are
   several RLP frame formats.  RLP frame formats with higher payload
   were designed for higher data rates.  Depending on the channel speed,
   one or more RLP frames can be transmitted in a single physical layer
   frame.

   RLP can substantially decrease the error rate exhibited by CDMA
   traffic channels [53].  When transferring data, RLP is a pure NAK-
   based finite selective repeat protocol.  The receiver does not
   acknowledge successfully received data frames.  If one or more RLP
   data frames are missing, the receiving RLP makes several attempts
   (called NAK rounds) to recover them by sending one or more NAK
   control frames to the transmitter.  Each NAK frame must be sent in a
   separate physical layer frame.  When RLP supplies the last NAK
   control frame of a particular NAK round, a retransmission timer is
   set.  If the missing frame is not received when the timer expires,
   RLP may try another NAK round.  RLP may not recover all missing
   frames.  If after all RLP rounds, a frame is still missing, RLP
   supplies data with a missing frame to the higher layer protocols.

4. TCP over 2.5G and 3G

   What follows is a set of recommendations for configuration parameters
   for protocol stacks which will be used to support TCP connections
   over 2.5G and 3G wireless networks.  Some of these recommendations
   imply special configuration:



Inamura, et al.          Best Current Practice                 [Page 10]
^L
RFC 3481                    TCP over 2.5G/3G               February 2003


   o  at the data receiver (frequently a stack at or near the wireless
      device),

   o  at the data sender (frequently a host in the Internet or possibly
      a gateway or proxy at the edge of a wireless network), or

   o  at both.

   These configuration options are commonly available IETF standards-
   track mechanisms considered safe on the general Internet.  System
   administrators are cautioned, however, that increasing the MTU size
   (Section 4.4) and disabling RFC 1144 header compression (Section 4.9)
   could affect host efficiency, and that changing such parameters
   should be done with care.

4.1 Appropriate Window Size (Sender & Receiver)

   TCP over 2.5G/3G should support appropriate window sizes based on the
   Bandwidth Delay Product (BDP) of the end-to-end path (see Section
   2.2).  The TCP specification [14] limits the receiver window size to
   64 KB.  If the end-to-end BDP is expected to be larger than 64 KB,
   the window scale option [2] can be used to overcome that limitation.
   Many operating systems by default use small TCP receive and send
   buffers around 16KB.  Therefore, even for a BDP below 64 KB, the
   default buffer size setting should be increased at the sender and at
   the receiver to allow a large enough window.

4.2 Increased Initial Window (Sender)

   TCP controls its transmit rate using the congestion window mechanism.
   The traditional initial window value of one segment, coupled with the
   delayed ACK mechanism [17] implies unnecessary idle times in the
   initial phase of the connection, including the delayed ACK timeout
   (typically 200 ms, but potentially as much as 500 ms) [4].  Senders
   can avoid this by using a larger initial window of up to four
   segments (not to exceed roughly 4 KB) [4].  Experiments with
   increased initial windows  and related measurements have shown (1)
   that it is safe to deploy this mechanism (i.e., it does not lead to
   congestion collapse), and (2) that it is especially effective for the
   transmission of a few TCP segments' worth of data (which is the
   behavior commonly seen in such applications as Internet-enabled
   mobile wireless devices).  For large data transfers, on the other
   hand, the effect of this mechanism is negligible.

   TCP over 2.5G/3G SHOULD set the initial CWND (congestion window)
   according to Equation 1 in [4]:

                   min (4*MSS, max (2*MSS, 4380 bytes))



Inamura, et al.          Best Current Practice                 [Page 11]
^L
RFC 3481                    TCP over 2.5G/3G               February 2003


   This increases the permitted initial window from one to between two
   and four segments (not to exceed approximately 4 KB).

4.3 Limited Transmit (Sender)

   RFC 3042 [10], Limited Transmit, extends Fast Retransmit/Fast
   Recovery for TCP connections with small congestion windows that are
   not likely to generate the three duplicate acknowledgements required
   to trigger Fast Retransmit [1].  If a sender has previously unsent
   data queued for transmission, the limited transmit mechanism calls
   for sending a new data segment in response to each of the first two
   duplicate acknowledgments that arrive at the sender.  This mechanism
   is effective when the congestion window size is small or if a large
   number of segments in a window are lost.  This may avoid some
   retransmissions due to TCP timeouts.  In particular, some studies
   [10] have shown that over half of a busy server's retransmissions
   were due to RTO expiration (as opposed to Fast Retransmit), and that
   roughly 25% of those could have been avoided using Limited Transmit.
   Similar to the discussion in Section 4.2, this mechanism is useful
   for small amounts of data to be transmitted.  TCP over 2.5G/3G
   implementations SHOULD implement Limited Transmit.

4.4 IP MTU Larger than Default

   The maximum size of an IP datagram supported by a link layer is the
   MTU (Maximum Transfer Unit).  The link layer may, in turn, fragment
   IP datagrams into PDUs.  For example, on links with high error rates,
   a smaller link PDU size increases the chance of successful
   transmission.  With layer two ARQ and transparent link layer
   fragmentation, the network layer can enjoy a larger MTU even in a
   relatively high BER (Bit Error Rate) condition.  Without these
   features in the link, a smaller MTU is suggested.

   TCP over 2.5G/3G should allow freedom for designers to choose MTU
   values ranging from small values (such as 576 bytes) to a large value
   that is supported by the type of link in use (such as 1500 bytes for
   IP packets on Ethernet).  Given that the window is counted in units
   of segments, a larger MTU allows TCP to increase the congestion
   window faster [5].  Hence, designers are generally encouraged to
   choose larger values.  These may exceed the default IP MTU values of
   576 bytes for IPv4 RFC 1191 [6] and 1280 bytes for IPv6 [18].  While
   this recommendation is applicable to 3G networks, operation over 2.5G
   networks should exercise caution as per the recommendations in RFC
   3150 [5].







Inamura, et al.          Best Current Practice                 [Page 12]
^L
RFC 3481                    TCP over 2.5G/3G               February 2003


4.5 Path MTU Discovery (Sender & Intermediate Routers)

   Path MTU discovery allows a sender to determine the maximum end-to-
   end transmission unit (without IP fragmentation) for a given routing
   path.  RFC 1191 [6] and RFC 1981 [8] describe the MTU discovery
   procedure for IPv4 and IPv6, respectively.  This allows TCP senders
   to employ larger segment sizes (without causing IP layer
   fragmentation) instead of assuming the small default MTU.  TCP over
   2.5G/3G implementations should implement Path MTU Discovery.  Path
   MTU Discovery requires intermediate routers to support the generation
   of the necessary ICMP messages.  RFC 1435 [7] provides
   recommendations that may be relevant for some router implementations.

4.6 Selective Acknowledgments (Sender & Receiver)

   The selective acknowledgment option (SACK), RFC 2018 [3], is
   effective when multiple TCP segments are lost in a single TCP window
   [24].  In particular, if the end-to-end path has a large BDP and a
   high packet loss rate, the probability of multiple segment losses in
   a single window of data increases.  In such cases, SACK provides
   robustness beyond TCP-Tahoe and TCP-Reno [21].  TCP over 2.5G/3G
   SHOULD support SACK.

   In the absence of SACK feature, the TCP should use NewReno RFC 2582
   [15].

4.7 Explicit Congestion Notification (Sender, Receiver & Intermediate
    Routers)

   Explicit Congestion Notification, RFC 3168 [9], allows a TCP receiver
   to inform the sender of congestion in the network by setting the
   ECN-Echo flag upon receiving an IP packet marked with the CE bit(s).
   The TCP sender will then reduce its congestion window.  Thus, the use
   of ECN is believed to provide performance benefits [32], [43].  RFC
   3168 [9] also places requirements on intermediate routers (e.g.,
   active queue management and setting of the CE bit(s) in the IP header
   to indicate congestion).  Therefore, the potential improvement in
   performance can only be achieved when ECN capable routers are
   deployed along the path.  TCP over 2.5G/3G SHOULD support ECN.

4.8 TCP Timestamps Option (Sender & Receiver)

   Traditionally, TCPs collect one RTT sample per window of data [14],
   [17].  This can lead to an underestimation of the RTT, and spurious
   timeouts on paths in which the packet transmission delay dominates
   the RTT.  This holds despite a conservative retransmit timer such as
   the one specified in RFC 2988 [11].  TCP connections with large
   windows may benefit from more frequent RTT samples provided with



Inamura, et al.          Best Current Practice                 [Page 13]
^L
RFC 3481                    TCP over 2.5G/3G               February 2003


   timestamps by adapting quicker to changing network conditions [2].
   However, there is some empirical evidence that for TCPs with an RFC
   2988 timer [11], timestamps provide little or no benefits on backbone
   Internet paths [59].   Using the TCP Timestamps option has the
   advantage that retransmitted segments can be used for RTT
   measurement, which is otherwise forbidden by Karn's algorithm [17],
   [11].  Furthermore, the TCP Timestamps option is the basis for
   detecting spurious retransmits using the Eifel algorithm [30].

   A 2.5/3G link (layer) is dedicated to a single host.  It therefore
   only experiences a low degree of statistical multiplexing between
   different flows.  Also, the packet transmission and queuing delays of
   a 2.5/3G link often dominate the path's RTT.  This already results in
   large RTT variations as packets fill the queue while a TCP sender
   probes for more bandwidth, or as packets drain from the queue while a
   TCP sender reduces its load in response to a packet loss.  In
   addition, the delay spikes across a 2.5/3G link (see Section 2.4) may
   often exceed the end-to-end RTT.  The thus resulting large variations
   in the path's RTT may often cause spurious timeouts.

   When running TCP in such an environment, it is therefore advantageous
   to sample the path's RTT more often than only once per RTT.  This
   allows the TCP sender to track changes in the RTT more closely.  In
   particular, a TCP sender can react more quickly to sudden increases
   of the RTT by sooner updating the RTO to a more conservative value.
   The TCP Timestamps option [2] provides this capability, allowing the
   TCP sender to sample the RTT from every segment that is acknowledged.
   Using timestamps in the mentioned scenario leads to a more
   conservative TCP retransmission timer and reduces the risk of
   triggering spurious timeouts [45], [52], [54], [60].

   There are two problematic issues with using timestamps:

   o  12 bytes of overhead are introduced by carrying the TCP Timestamps
      option and padding in the TCP header.  For a small MTU size, it
      can present a considerable overhead.  For example, for an MTU of
      296 bytes the added overhead is 4%.  For an MTU of 1500 bytes, the
      added overhead is only 0.8%.

   o  Current TCP header compression schemes are limited in their
      handling of the TCP options field.  For RFC 2507 [13], any change
      in the options field (caused by timestamps or SACK, for example)
      renders the entire field uncompressible (leaving the TCP/IP header
      itself compressible, however).  Even worse, for RFC 1144 [40] such
      a change in the options field effectively disables TCP/IP header
      compression altogether.  This is the case when a connection uses
      the TCP Timestamps option.  That option field is used both in the
      data and the ACK path, and its value typically changes from one



Inamura, et al.          Best Current Practice                 [Page 14]
^L
RFC 3481                    TCP over 2.5G/3G               February 2003


      packet to the next.  The IETF is currently specifying a robust
      TCP/IP header compression scheme with better support for TCP
      options [29].

   The original definition of the timestamps option [2] specifies that
   duplicate segments below cumulative ACK do not update the cached
   timestamp value at the receiver.  This may lead to overestimating of
   RTT for retransmitted segments.  A possible solution [47] allows the
   receiver to use a more recent timestamp from a duplicate segment.
   However, this suggestion allows for spoofing attacks against the TCP
   receiver.  Therefore,  careful consideration is needed in
   implementing this solution.

   Recommendation: TCP SHOULD use the TCP Timestamps option.  It allows
   for better RTT estimation and reduces the risk of spurious timeouts.

4.9 Disabling RFC 1144 TCP/IP Header Compression (Wireless Host)

   It is well known (and has been shown with experimental data) that RFC
   1144 [40] TCP header compression does not perform well in the
   presence of packet losses [43], [52].  If a wireless link error is
   not recovered, it will cause TCP segment loss between the compressor
   and decompressor, and then RFC 1144 header compression does not allow
   TCP to take advantage of Fast Retransmit Fast Recovery mechanism.
   The RFC 1144 header compression algorithm does not transmit the
   entire TCP/IP headers, but only the changes in the headers of
   consecutive segments.  Therefore, loss of a single TCP segment on the
   link causes the transmitting and receiving TCP sequence numbers to
   fall out of synchronization.   Hence, when a TCP segment is lost
   after the compressor, the decompressor will generate false TCP
   headers.  Consequently, the TCP receiver will discard all remaining
   packets in the current window because of a checksum error.  This
   continues until the compressor receives the first retransmission
   which is forwarded uncompressed to synchronize the decompressor [40].

   As previously recommended in RFC 3150 [5], RFC 1144 header
   compression SHOULD NOT be enabled unless the packet loss probability
   between the compressor and decompressor is very low.  Actually,
   enabling the Timestamps Option effectively accomplishes the same
   thing (see Section 4.8).  Other header compression schemes like RFC
   2507 [13] and Robust Header Compression [12] are meant to address
   deficiencies in RFC 1144 header compression.  At the time of this
   writing, the IETF was working on multiple extensions to Robust Header
   Compression (negotiating Robust Header Compression over PPP,
   compressing TCP options, etc) [16].






Inamura, et al.          Best Current Practice                 [Page 15]
^L
RFC 3481                    TCP over 2.5G/3G               February 2003


4.10 Summary

   Items                                   Comments
   ----------------------------------------------------------------
   Appropriate Window Size         (sender & receiver)
                                   based on end-to-end BDP

   Window Scale Option             (sender & receiver)
   [RFC1323]                       Window size > 64KB

   Increased Initial Window        (sender)
   [RFC3390]                       CWND = min (4*MSS,
                                   max (2*MSS, 4380 bytes))

   Limited Transmit                (sender)
   [RFC3042]

   IP MTU larger than              more applicable to 3G
   Default

   Path MTU Discovery              (sender & intermediate routers)
   [RFC1191,RFC1981]

   Selective Acknowledgment
   option (SACK)
   [RFC2018]                       (sender & receiver)

   Explicit Congestion
   Notification(ECN)
   [RFC3168]                       (sender, receiver &
                                   intermediate routers)

   Timestamps Option               (sender & receiver)
   [RFC1323, R.T.Braden's ID]

   Disabling RFC1144
   TCP/IP Header Compression
   [RFC1144]                       (wireless host)

5. Open Issues

   This section outlines additional mechanisms and parameter settings
   that may increase end-to-end performance when running TCP across
   2.5G/3G networks.  Note, that apart from the discussion of the RTO's
   initial value, those mechanisms and parameter settings are not part
   of any standards track RFC at the time of this writing.  Therefore,
   they cannot be recommended for the Internet in general.




Inamura, et al.          Best Current Practice                 [Page 16]
^L
RFC 3481                    TCP over 2.5G/3G               February 2003


   Other mechanisms for increasing TCP performance include enhanced TCP/
   IP header compression schemes [29], active queue management RFC 2309
   [28], link layer retransmission schemes [23], and caching packets
   during transient link outages to retransmit them locally when the
   link is restored to operation [23].

   Shortcomings of existing TCP/IP header compression schemes (RFC 1144
   [40], RFC 2507 [13]) are that they do not compress headers of
   handshaking packets (SYNs and FINs), and that they lack proper
   handling of TCP option fields (e.g., SACK or timestamps) (see Section
   4.8).   Although RFC 3095 [12] does not yet address this issue, the
   IETF is developing improved TCP/IP header compression schemes,
   including better handling of TCP options such as timestamps and
   selective acknowledgements.  Especially, if many short-lived TCP
   connections run across the link, the compression of the handshaking
   packets may greatly improve the overall header compression ratio.

   Implementing active queue management is attractive for a number of
   reasons as outlined in RFC 2309 [28].  One important benefit for
   2.5G/ 3G networks, is that it minimizes the amount of potentially
   stale data that may be queued in the network ("clicking from page to
   page" before the download of the previous page is complete).
   Avoiding the transmission of stale data across the 2.5G/3G radio link
   saves transmission (battery) power, and increases the ratio of useful
   data over total data transmitted.  Another important benefit of
   active queue management for 2.5G/3G networks, is that it reduces the
   risk of a spurious timeout for the first data segment as outlined
   below.

   Since 2.5G/3G networks are commonly characterized by high delays,
   avoiding unecessary round-trip times is particularly attractive.
   This is specially beneficial for short-lived, transactional (request/
   response-style) TCP sessions that typically result from browsing the
   Web from a smart phone.  However, existing solutions such as T/TCP
   RFC 1644 [27], have not been adopted due to known security concerns
   [38].

   Spurious timeouts, packet re-ordering, and packet duplication may
   reduce TCP's performance.  Thus, making TCP more robust against those
   events is desirable.  Solutions to this problem have been proposed
   [30], [35], [41], and standardization work within the IETF is ongoing
   at the time of writing.  Those solutions include reverting congestion
   control state after such an event has been detected, and adapting the
   retransmission timer and duplicate acknowledgement threshold.  The
   deployment of such solutions may be particularly beneficial when
   running TCP across wireless networks because wireless access links
   may often be subject to handovers and resource preemption, or the
   mobile transmitter may traverse through a radio coverage hole.  Such



Inamura, et al.          Best Current Practice                 [Page 17]
^L
RFC 3481                    TCP over 2.5G/3G               February 2003


   disrupting events may easily trigger a spurious timeout despite a
   conservative retransmission timer.  Also, the mobility mechanisms of
   some wireless networks may cause packet duplication.

   The algorithm for computing TCP's retransmission timer is specified
   in RFC 2988 [11].  The standard specifies that the initial setting of
   the retransmission timeout value (RTO) should not be less than 3
   seconds.  This value might be too low when running TCP across 2.5G/3G
   networks.  In addition to its high latencies, those networks may be
   run at bit rates of as low as about 10 kb/s which results in large
   packet transmission delays.  In this case, the RTT for the first data
   segment may easily exceed the initial TCP retransmission timer
   setting of 3 seconds.  This would then cause a spurious timeout for
   that segment.  Hence, in such situations it may be advisable to set
   TCP's initial RTO to a value larger than 3 seconds.  Furthermore, due
   to the potentially large packet transmission delays, a TCP sender
   might choose to refrain from initializing its RTO from the RTT
   measured for the SYN, but instead take the RTT measured for the first
   data segment.

   Some of the recommendations in RFC 2988 [11] are optional, and are
   not followed by all TCP implementations.  Specifically, some TCP
   stacks allow a minimum RTO less than the recommended value of 1
   second (section 2.4 of [11]), and some implementations do not
   implement the recommended restart of the RTO timer when an ACK is
   received (section 5.3 of [11]).  Some experiments [52], [54], have
   shown that in the face of bandwidth oscillation, using the
   recommended minimum RTO value of 1 sec (along with the also
   recommended initial RTO of 3 sec) reduces the number of spurious
   retransmissions as compared to using small minimum RTO values of 200
   or 400 ms.  Furthermore, TCP stacks that restart the retransmission
   timer when an ACK is received experience far less spurious
   retransmissions than implementations that do not restart the RTO
   timer when an ACK is received.  Therefore, at the time of this
   writing, it seems preferable for TCP implementations used in 3G
   wireless data transmission to comply with all recommendations of RFC
   2988.

6. Security Considerations

   In 2.5G/3G wireless networks, data is transmitted as ciphertext over
   the air and as cleartext between the Radio Access Network (RAN) and
   the core network.  IP security RFC 2401 [37] or TLS RFC 2246 [36] can
   be deployed by user devices for end-to-end security.

7. IANA Considerations

   This specification requires no IANA actions.



Inamura, et al.          Best Current Practice                 [Page 18]
^L
RFC 3481                    TCP over 2.5G/3G               February 2003


8. Acknowledgements

   The authors would like to acknowledge contributions to the text from
   the following individuals:

      Max Hata, NTT DoCoMo, Inc.  (hata@mml.yrp.nttdocomo.co.jp)

      Masahiro Hara, Fujitsu, Inc.  (mhara@FLAB.FUJITSU.CO.JP)

      Joby James, Motorola, Inc.  (joby@MIEL.MOT.COM)

      William Gilliam, Hewlett-Packard Company (wag@cup.hp.com)

      Alan Hameed, Fujitsu FNC, Inc. (Alan.Hameed@fnc.fujitsu.com)

      Rodrigo Garces, Mobility Network Systems
                             (rodrigo.garces@mobilitynetworks.com)

      Peter Ford, Microsoft (peterf@Exchange.Microsoft.com)

      Fergus Wills, Openwave (fergus.wills@openwave.com)

      Michael Meyer (Michael.Meyer@eed.ericsson.se)

   The authors gratefully acknowledge the valuable advice from the
   following individuals:

      Gorry Fairhurst (gorry@erg.abdn.ac.uk)

      Mark Allman (mallman@grc.nasa.gov)

      Aaron Falk (falk@ISI.EDU)

9. Normative References

   [1]  Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control",
        RFC 2581, April 1999.

   [2]  Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High
        Performance", RFC 1323, May 1992.

   [3]  Mathis, M., Mahdavi, J., Floyd, S. and R. Romanow, "TCP
        Selective Acknowledgment Options", RFC 2018, October 1996.

   [4]  Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's
        Initial Window", RFC 3390, October 2002.





Inamura, et al.          Best Current Practice                 [Page 19]
^L
RFC 3481                    TCP over 2.5G/3G               February 2003


   [5]  Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, "End-to-end
        Performance Implications of Slow Links", BCP 48, RFC 3150, July
        2001.

   [6]  Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
        November 1990.

   [7]  Knowles, S., "IESG Advice from Experience with Path MTU
        Discovery", RFC 1435, March 1993.

   [8]  McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP
        version 6", RFC 1981, August 1996.

   [9]  Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of
        Explicit Congestion Notification (ECN) to IP", RFC 3168,
        September 2001.

  [10]  Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing TCP's Loss
        Recovery Using Limited Transmit", RFC 3042, January 2001.

  [11]  Paxson, V. and M. Allman, "Computing TCP's Retransmission
        Timer", RFC 2988, November 2000.

  [12]  Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
        Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu,
        Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
        Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC):
        Framework and four profiles: RTP, UDP, ESP, and uncompressed",
        RFC 3095, July 2001.

  [13]  Degermark, M., Nordgren, B. and S. Pink, "IP Header
        Compression", RFC 2507, February 1999.

  [14]  Postel, J., "Transmission Control Protocol - DARPA Internet
        Program Protocol Specification", STD 7, RFC 793, September 1981.

  [15]  Floyd, S. and T. Henderson, "The NewReno Modification to TCP's
        Fast Recovery Algorithm", RFC 2582, April 1999.

  [16]  Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC
        3241, April 2002.

  [17]  Braden, R., "Requirements for Internet Hosts - Communication
        Layers", STD 3, RFC 1122, October 1989.

  [18]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC 2460, December 1998.




Inamura, et al.          Best Current Practice                 [Page 20]
^L
RFC 3481                    TCP over 2.5G/3G               February 2003


10. Informative References

  [19]  Montenegro, G., Dawkins, S., Kojo, M., Magret, V. and N.
        Vaidya, "Long Thin Networks", RFC 2757, January 2000.

  [20]  Third Generation Partnership Project, "RLC Protocol
        Specification (3G TS 25.322:)", 1999.

  [21]  Fall, K. and S. Floyd, "Simulation-based Comparisons of Tahoe,
        Reno, and SACK TCP", Computer Communication Review, 26(3) , July
        1996.

  [22]  Fairhurst, G. and L. Wood, "Advice to link designers on link
        Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, August 2002.

  [23]  Karn, P., "Advice for Internet Subnetwork Designers", Work in
        Progress.

  [24]  Dawkins, S., Montenegro, G., Magret, V., Vaidya, N. and M.
        Kojo, "End-to-end Performance Implications of Links with
        Errors", BCP 50, RFC 3135, August 2001.

  [25]  Wireless Application Protocol, "WAP Specifications", 2002,
        <http://www.wapforum.org>.

  [26]  Open Mobile Alliance, "Open Mobile Alliance", 2002,
        <http://www.openmobilealliance.org/>.

  [27]  Braden, R., "T/TCP -- TCP Extensions for Transactions", RFC
        1644, July 1994.

  [28]  Braden, R., Clark, D., Crowcroft, J., Davie, B., Deering, S.,
        Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge,
        C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J.
        and L. Zhang, "Recommendations on Queue Management and
        Congestion Avoidance in the Internet", RFC 2309, April 1998.

  [29]  IETF, "Robust Header Compression", 2001,
        <http://www.ietf.org/html.charters/rohc-charter.html>.

  [30]  Ludwig, R. and R. H. Katz, "The Eifel Algorithm: Making TCP
        Robust Against Spurious Retransmissions", ACM Computer
        Communication Review 30(1), January 2000.

  [31]  Wireless Application Protocol, "WAP Wireless Profiled TCP",
        WAP-225-TCP-20010331-a, April 2001,
        <http://www.wapforum.com/what/technical.htm>.




Inamura, et al.          Best Current Practice                 [Page 21]
^L
RFC 3481                    TCP over 2.5G/3G               February 2003


  [32]  Hadi Salim, J. and U. Ahmed, "Performance Evaluation of Explicit
        Congestion Notification (ECN) in IP Networks", RFC 2884, July
        2000.

  [33]  NTT DoCoMo Technical Journal, "Special Issue on i-mode Service",
        October 1999.

  [34]  NTT DoCoMo Technical Journal, "Special Article on IMT-2000
        Services", September 2001.

  [35]  Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "An
        Extension to the Selective Acknowledgement (SACK) Option for
        TCP", RFC 2883, July 2000.

  [36]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
        2246, January 1999.

  [37]  Kent, S. and R. Atkinson, "Security Architecture for the
        Internet Protocol", RFC 2401, November 1998.

  [38]  de Vivo, M., O. de Vivo, G., Koeneke, R. and G. Isern, "Internet
        Vulnerabilities Related to TCP/IP and T/TCP", ACM Computer
        Communication Review 29(1), January 1999.

  [39]  Third Generation Partnership Project, "RRC Protocol
        Specification (3GPP TS 25.331:)", September 2001.

  [40]  Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial
        Links", RFC 1144, February 1990.

  [41]  Blanton, E. and M. Allman, "On Making TCP More Robust to Packet
        Reordering", ACM Computer Communication Review 32(1), January
        2002, <http://roland.grc.nasa.gov/~mallman/papers/tcp-reorder-
        ccr.ps>.

  [42]  Karn, P. and C. Partridge, "Improving Round-Trip Time Estimates
        in Reliable Transport Protocols", ACM SIGCOMM 87, 1987.

  [43]  Ludwig, R., Rathonyi, B., Konrad, A. and A. Joseph, "Multi-layer
        tracing of TCP over a reliable wireless link", ACM SIGMETRICS
        99, May 1999.

  [44]  Ludwig, R., Konrad, A., Joseph, A. and R. Katz, "Optimizing the
        End-to-End Performance of Reliable Flows over Wireless Links",
        Kluwer/ACM Wireless Networks Journal Vol. 8, Nos. 2/3, pp. 289-
        299, March-May 2002.





Inamura, et al.          Best Current Practice                 [Page 22]
^L
RFC 3481                    TCP over 2.5G/3G               February 2003


  [45]  Gurtov, A., "Making TCP Robust Against Delay Spikes", University
        of Helsinki, Department of Computer Science, Series of
        Publications C, C-2001-53, Nov 2001,
        <http://www.cs.helsinki.fi/u/gurtov/papers/report01.html>.

  [46]  Stevens, W., "TCP/IP Illustrated, Volume 1; The Protocols",
        Addison Wesley, 1995.

  [47]  Braden, R., "TCP Extensions for High Performance: An Update",
        Work in Progress.

  [48]  Allman, M., Dawkins, S., Glover, D., Griner, J., Tran, D.,
        Henderson, T., Heidemann, J., Touch, J., Kruse, H., Ostermann,
        S., Scott, K. and J. Semke, "Ongoing TCP Research Related to
        Satellites", RFC 2760, February 2000.

  [49]  Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over
        Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488,
        January 1999.

  [50]  Balakrishnan, H., Padmanabhan, V., Fairhurst, G. and M.
        Sooriyabandara, "TCP Performance Implications of Network
        Asymmetry", RFC 3449, December 2002.

  [51]  Kempf, J., "Problem Description: Reasons For Performing Context
        Transfers Between Nodes in an IP Access Network", RFC 3374,
        September 2002.

  [52]  Khafizov, F. and M. Yavuz, "Running TCP over IS-2000", Proc. of
        IEEE ICC, 2002.

  [53]  Khafizov, F. and M. Yavuz, "Analytical Model of RLP in IS-2000
        CDMA Networks", Proc. of IEEE Vehicular Technology Conference,
        September 2002.

  [54]  Yavuz, M. and F. Khafizov, "TCP over Wireless Links with
        Variable Bandwidth", Proc. of IEEE Vehicular Technology
        Conference, September 2002.

  [55]  TIA/EIA/cdma2000, "Mobile Station - Base Station Compatibility
        Standard for Dual-Mode Wideband Spread Spectrum Cellular
        Systems", Washington: Telecommunication Industry Association,
        1999.

  [56]  TIA/EIA/IS-95 Rev A, "Mobile Station - Base Station
        Compatibility Standard for Dual-Mode Wideband Spread Spectrum
        Cellular Systems", Washington: Telecommunication Industry
        Association, 1995.



Inamura, et al.          Best Current Practice                 [Page 23]
^L
RFC 3481                    TCP over 2.5G/3G               February 2003


  [57]  TIA/EIA/IS-707-A-2.10, "Data Service Options for Spread Spectrum
        Systems: Radio Link Protocol Type 3", January 2000.

  [58]  Dahlman, E., Beming, P., Knutsson, J., Ovesjo, F., Persson, M.
        and C. Roobol, "WCDMA - The Radio Interface for Future Mobile
        Multimedia Communications", IEEE Trans. on Vehicular Technology,
        vol. 47, no. 4, pp. 1105-1118, November 1998.

  [59]  Allman, M. and V. Paxson, "On Estimating End-to-End Network Path
        Properties", ACM SIGCOMM 99, September 1999.

  [60]  Gurtov, A. and R. Ludwig, "Responding to Spurious Timeouts in
        TCP", IEEE INFOCOM'03, March 2003.






































Inamura, et al.          Best Current Practice                 [Page 24]
^L
RFC 3481                    TCP over 2.5G/3G               February 2003


11. Authors' Addresses

   Hiroshi Inamura
   NTT DoCoMo, Inc.
   3-5 Hikarinooka
   Yokosuka Shi, Kanagawa Ken  239-8536
   Japan

   EMail: inamura@mml.yrp.nttdocomo.co.jp
   URI:   http://www.nttdocomo.co.jp/


   Gabriel Montenegro
   Sun Microsystems Laboratories, Europe
   Avenue de l'Europe
   ZIRST de Montbonnot
   38334 Saint Ismier CEDEX
   France

   EMail: gab@sun.com


   Reiner Ludwig
   Ericsson Research
   Ericsson Allee 1
   52134 Herzogenrath
   Germany

   EMail: Reiner.Ludwig@Ericsson.com


   Andrei Gurtov
   Sonera
   P.O. Box 970, FIN-00051
   Helsinki,
   Finland

   EMail: andrei.gurtov@sonera.com
   URI:   http://www.cs.helsinki.fi/u/gurtov/


   Farid Khafizov
   Nortel Networks
   2201 Lakeside Blvd
   Richardson, TX 75082,
   USA

   EMail: faridk@nortelnetworks.com



Inamura, et al.          Best Current Practice                 [Page 25]
^L
RFC 3481                    TCP over 2.5G/3G               February 2003


12. Full Copyright Statement

   Copyright (C) The Internet Society (2003).  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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Inamura, et al.          Best Current Practice                 [Page 26]
^L