doc: Add RFC documents

1 files changed, 1459 insertions, 0 deletions

diff --git a/doc/rfc/rfc3481.txt b/doc/rfc/rfc3481.txt
new file mode 100644
index 0000000..6c45efe
--- /dev/null
+++ b/doc/rfc/rfc3481.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+