Subject: draft-ietf-pilc-2.5g3g-03

From: "Hiroshi INAMURA" <[email-masked]>
Date: Thu, 5 Jul 2001 23:27:49 +0900

Hi,

This is revised text for the pilc wg document.

Regards,

Hiroshi Inamura
NTTDoCoMo
Multimedial Labs,

Network Working Group                                H. Inamura (editor)
Internet-Draft                                          NTT DoCoMo, Inc.
Expires: January 3, 2002                                   G. Montenegro
                                                  Sun Microsystems, Inc.
M. Hara                                                          M. Hata
Fujitsu, Inc.                                           NTT DoCoMo, Inc.
W. Gilliam                                                      J. James
Hewlett-Packard Company                                   Motorola, Inc.
R. Ludwig                                                      A. Hameed
Ericsson Research                                      Fujitsu FNC, Inc.
P. Ford                                                        R. Garces
Microsoft                                                       Metricom
                                                                F. Wills
                                                                Openwave

                                                           July 05, 2001

                 TCP over 2.5G and 3G Wireless Networks
                       draft-ietf-pilc-2.5g3g-03

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Comments should be submitted to the PILC mailing list at
   [email-masked].
   Distribution of this memo is unlimited.

Inamura, et. al.        Expires January 3, 2002                 [Page 1]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks       July 2001

   This Internet-Draft will expire on January 3, 2002.

Copyright Notice

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

Abstract

   This document describes a profile for optimizing TCP over 2.5G/3G
   wireless networks. We describe the link characteristics of 3G
   wireless by using W-CDMA (Wideband CDMA) as an example. We then
   recommend TCP optimization mechanisms and, finally, present examples
   of wireless internet services and standardization activities. These
   potentially will deploy the profile described in this document. 

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    2.5G and 3G Link Characteristics . . . . . . . . . . . . . .  4
   3.    TCP over 2.5G and 3G . . . . . . . . . . . . . . . . . . . .  5
   3.1   Optimization Mechanisms  . . . . . . . . . . . . . . . . . .  5
   3.1.1 Large window size  . . . . . . . . . . . . . . . . . . . . .  5
   3.1.2 Large initial window . . . . . . . . . . . . . . . . . . . .  5
   3.1.3 Limited Transmit . . . . . . . . . . . . . . . . . . . . . .  6
   3.1.4 Large MTU  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.1.5 Path MTU discovery . . . . . . . . . . . . . . . . . . . . .  6
   3.1.6 Selective Acknowledgments  . . . . . . . . . . . . . . . . .  7
   3.1.7 Explicit Congestion Notification . . . . . . . . . . . . . .  7
   3.1.8 Summary  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   3.2   Applications . . . . . . . . . . . . . . . . . . . . . . . .  8
   3.2.1 i-mode . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   3.2.2 WAP  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   3.2.3 Ricochet MCDN Network  . . . . . . . . . . . . . . . . . . .  9
   4.    Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . 11
   5.    Security Considerations  . . . . . . . . . . . . . . . . . . 12
         References . . . . . . . . . . . . . . . . . . . . . . . . . 13
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 19

Inamura, et. al.        Expires January 3, 2002                 [Page 2]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks       July 2001

1. Introduction

   Recently, much development and deployment activity has centered
   around GPRS, UMTS and IMT-2000, also referred to as 2.5G/3G wireless
   networks. Since a primary motivation for these is data
   communication, and, in particular, Internet access, TCP performance
   is a key issue. 

   A number of TCP optimization techniques have been studied to enhance
   the performance of TCP transmission for various wireless
   environments [1]. 

   This document proposes a profile of such techniques, derived from
   previous work at the IETF [34], particularly effective for use with
   2.5G and 3G wireless networks. 

Inamura, et. al.        Expires January 3, 2002                 [Page 3]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks       July 2001

2. 2.5G and 3G Link Characteristics

   The link layer characteristics of 2.5G/3G network affects TCP
   performance over the link. The characteristics are layer two ARQ (L2
   ARQ), FEC (forward error correction) and so on [1]. The
   justification for L2 ARQ is discussed in [10], [12]. 

   For example, W-CDMA (Wideband CDMA) uses RLC (Radio Link Control)
   [3] protocol, that is a kind of Selective Repeat and sliding window
   ARQ. RLC uses protocol data units (PDUs) 336 bits long (including a
   16 bit RLC header). This is the unit for retransmission. The SDU (IP
   packet) is fragmented into PDUs for transmission by RLC. 

   There is also FEC and interleaving. In W-CDMA, one to twelve PDUs
   (RLC frames) constitute one FEC frame. The actual size of the FEC
   frame depends on the link conditions and bandwidth allocation. The
   FEC frame is the unit of interleaving. 

   RLC uses "status report" type acknowledgments. It does not use
   ack-clocking as in TCP, but rather the poll bit in the header
   explicitly solicits the peer for a status report containing the
   sequence number that the peer acknowledged. 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 invoke retransmission.
   RLC preserves order of packet delivery 

   The maximum number of retransmissions is a configurable RLC
   parameter, with a maximum value of 10. Therefore, RLC can be
   described as an ARQ that can be configured in either
   HIGH-PERSISTENCE or LOW-PERSISTENCE, not PERFECTLY-PERSISTENT,
   according to the terminology in [10]. 

   In general, the L2 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. The SDU (IP packet) is fragmented into PDUs
   for transmission. The retransmission by L2 ARQ introduces latency
   and jitter to the SDU flow, that results in relatively large BDP
   (Bandwidth-Delay Product) of the 2.5G/3G wireless networks. 

Inamura, et. al.        Expires January 3, 2002                 [Page 4]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks       July 2001

3. TCP over 2.5G and 3G

3.1 Optimization Mechanisms

3.1.1 Large window size

   To achieve the maximum performance in TCP, the advertised receive
   window size needs to be equal to or greater than the BDP (Bandwidth
   Delay Product) of the end-to-end path. 

   The wireless link capacity varies by specific technologies used. In
   2.5G/3G wireless, the link BDP tends to large. If the end-to-end
   path contains one or more wireless link, the end-to-end BDP might be
   larger than the default value of receive window size on many TCP
   implementations. The receiver must advertise the appropriate receive
   window size based on the end-to-end BDP. 

   The traditional TCP specification limits the window size to 64 KB.
   If the end-to-end capacity is expected to be larger than 64 KB, the
   window scale option [6] can overcome the limitation. TCP over
   2.5G/3G should support appropriate window sizes based on the BDP of
   the end-to-end path. If the estimated path BDP is larger than 64 KB,
   the window scale option may be deployed. 

3.1.2 Large initial window

   TCP controls its transmit rate using the congestion window
   mechanism. Traditionally, the initial value of the window is one
   segment. Because the delayed Ack mechanism is widely deployed, a TCP
   sender should have an increased initial congestion window of two
   segments[4]. This effectively cancels the delayed Ack by sending two
   segments at once in the very first slow start turn, that contributes
   to avoiding the overhead in the initial phase of the connection. 

   Furthermore, the increased initial window mechanism [5] is also
   effective, especially for small amounts of data to be transmitted,
   which is commonly seen in such an application as the
   Internet-enabled mobile wireless devices. For large data transfer,
   on the other hand, the effect of this mechanism is negligible. [7]
   describes evaluations of this mechanism by measurements. 

   Two segments of initial congestion window size is recommended in
   RFC2581[4]. RFC2414[5] also notes consideration on use of initial
   window size of more than two. Although the increased initial
   congestion window is experimental status, the impact of use of it to
   the majority of the Internet can be mitigated if the split
   architecture[36] is deployed that terminates TCP connection between
   the mobile node and the gateway and could set the CWND > 2 segments
   only to the TCP connection to the mobile node. Be careful on the

Inamura, et. al.        Expires January 3, 2002                 [Page 5]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks       July 2001

   implications caused by the use of the transport gateway, which
   includes end-to-end argument, mobility and security[36]. 

   Due to the fact that the delayed Ack mechanism is the standard and
   that the increased initial window option is especially effective for
   the small data transfer that is common for mobile wireless devices,
   TCP over 2.5G/3G should use initial CWND (congestion window) = 2
   segments. It may use CWND > 2 segments if a gateway is present. When
   applying CWND > 2 segments, it may also be applicable to the restart
   window. 

3.1.3 Limited Transmit

   RFC3042[30], Limited Transmit, is extending Fast Retransmit/Fast
   Recovery for TCP connections with small congestion windows that is
   not enough to generate three duplicate acknowledgements. The
   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 congestion window size is
   small or if a large number of segments in a window are lost. This
   may reduce the retransmission due to TCP round trip timeout. As the
   discussion in Section 3.1.2, this mechanism is useful for small
   amounts of data to be transmitted. TCP over 2.5G/3G implementations
   should implement Limited Transmit. 

3.1.4 Large MTU

   One of the link layer parameters is MTU (Maximum Transfer Unit). In
   TCP, the slow start mechanism tries to find an adequate rate for the
   network path. The larger MTU allows TCP to grow the congestion
   window faster [11], because the window is counted in unit of
   segments. In the link with error, smaller link PDU size is better in
   terms of the chance of successful transmission. With layer two ARQ
   and transparent link layer fragmentation, the network layer can
   enjoy larger MTU even in a relatively high BER (Bit Error Rate),
   condition. Without these features in the link, smaller MTU is
   better. TCP over 2.5G/3G should allow freedom for designers to
   choose MTU from a small value (such as 576B) to a large value (up to
   1500B). 

3.1.5 Path MTU discovery

   Path MTU discovery allows a sender to determine the maximum
   end-to-end transmission unit for a given routing path. RFC1191[21]
   and RFC1981[23] 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 default MTU.  TCP over 2.5G/3G implementations should implement
   Path MTU Discovery. Path MTU Discovery requires intermediate routers

Inamura, et. al.        Expires January 3, 2002                 [Page 6]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks       July 2001

   to support the generation of the necessary ICMP messages.
   RFC1993[22] provides recommendations that may be relevant for some
   router implementations. 

3.1.6 Selective Acknowledgments

   The selective acknowledgment option (SACK), RFC2018[8], is effective
   when multiple TCP segments are lost in a single TCP window [13] . In
   particular, if the end-to-end path has a large BDP and a certain
   amount of packet loss rate, the probability of multiple segment
   losses in a single window of data grows high. In such cases, SACK
   performs better than traditional and Reno TCP [9]. TCP over 2.5G/3G
   should support SACK. 

3.1.7 Explicit Congestion Notification

   Explicit Congestion Notification, RFC2481[25], allows a TCP receiver
   to inform the sender of congestion in the network by setting the
   ECN-Echo flag; a receiver will set this flag on receiving an IP
   packet marked with the CE bit. The TCP sender MUST then reduce its
   congestion window. The use of ECN is believed to provide performance
   benefits [24]. TCP over 2.5G/3G may support ECN. RFC2481[25] also
   places requirements on intermediate routers (e.g. active queue
   management and setting of the CE bit in the IP header to indicate
   congestion). Thus the use of ECN on the TCP connections is dependent
   on the necessary support from the relevant routers. 

Inamura, et. al.        Expires January 3, 2002                 [Page 7]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks       July 2001

3.1.8 Summary

   Items                                   Qualifier
   ----------------------------------------------------------------
   Large window size
   based on end-to-end BDP
   Window scale option                      Window size>64KB
   [RFC1323]
   Large initial window (CWND = 2 segments)
   [RFC2581]
   Large initial window (CWND > 2 segments) Behind a  gateway
   [RFC2414]
   Limited Transmit
   [RFC3042]
   Selective Acknowledgment option (SACK)
   [RFC2018]
   Path MTU discovery
   [RFC1191,RFC1981]M
   MTU larger than default IP MTU
   Explicit Congestion Notification(ECN)
   [RFC2481]

3.2 Applications

   We introduce wireless services deploying (or capable of deploying)
   the recommendation we discuss here. Net-enabled portable phones and
   wireless ISPs are the two major applications. 

3.2.1 i-mode

   Mobile terminal users want to enjoy the Internet experience on their
   handset. This market is emerging and growing rapidly. A deployment
   example is i-mode [27], a wireless Internet service. As of this
   writing, it is the largest single wireless internet service in the
   world, with 25 million subscribers in Japan. 

   The next version of i-mode that operates over W-CDMA, that is called
   FOMA [28], is launched at the end of May 2001. It deploys the
   profiled TCP that is described in this document. The browser
   embedded in the handset utilizes the higher speed of 3G
   infrastructure that can provide up to 384kbps packet mode service. 

   From the perspective of transport layer, the underlying W-CDMA
   network can be viewed as a network with a relatively large BDP and
   jitter. The loss rate of IP packets is low due to the ARQ, but the
   recovery in the layer two appears as jitter to the higher layers. 

   The i-mode infrastructure directly conveys IP packets to the gateway
   for accessing the Internet. In addition to the operation by the

Inamura, et. al.        Expires January 3, 2002                 [Page 8]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks       July 2001

   embedded browser, the i-mode handset can be connected to a computer,
   a PDA and the like as a wireless modem. In this mode, most of data
   communication facilities can be controlled via AT modem commands.
   The W-CDMA infrastructure, whose core network uses GPRS (General
   Packet Radio Service), can be viewed as a large PPP link to GGSN
   (Gateway GPRS Supporting Node). The other side of GGSN is connected
   to fixed networks of ISPs using, for example, leased lines. 

3.2.2 WAP

   The WAP Forum [14] is an industry association that has developed
   standards for wireless information and telephony services on digital
   mobile phones and other wireless terminals. In order to address WAP
   functionalities for high speed networks such as 2.5G and 3G networks
   and to aim at convergence to the Internet standards, the WAP Forum
   has been addressing adoption of TCP as its transport protocol,
   benefiting from relevant documents and discussions within IETF and,
   in particular, its PILC working group. 

   WAP Forum is releasing a new generation of specifications. The WAP
   specifications include a set of the recommended TCP options that is
   described in this submission. The specification of the profiled TCP
   is available for public review [20]. 

3.2.3 Ricochet MCDN Network

   Metricom, Inc. is a high-speed wireless data company. Its high-speed
   Ricochet mobile access delivers user speeds of 128 kbps, and is
   currently available in 15 metropolitan areas and 15 airports in the
   United States serving over 50 million potential customers. Ricochet
   acts like, feels like, and works like a high-speed wired network
   connection. It provides wireless access to information from outside
   the confines of an office or any single location. 

   Ricochet is a wide-area wireless packet data network. The
   architecture for the Ricochet system is based on Metricom's Micro
   Cellular Data Network (MCDN) technology. This architecture has seven
   physical components: 1) wireless modems or subscriber devices; 2) a
   cluster of MicroCells; 3) Wired Access Points; 4) a nation-wide
   wired backbone; 5) a MCDN Name Service; 6) a Network Management
   System; 7) and MCDN gateways. The MCDN system architecture is based
   on a mesh of MicroCells deployed throughout a metropolitan area and
   operates in accordance with FCC part 15.247 rules and regulations
   for the ISM band [26]. 

   When the user's computing device attempts to negotiate a PPP
   connection to the network, the radio modem establishes a virtual
   connection, analogous to TCP, to the MCDN gateway, which ensures
   that all of the packets from the user's computing device are routed

Inamura, et. al.        Expires January 3, 2002                 [Page 9]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks       July 2001

   to the Internet. The Wired Access Point provides the actual
   connection from the wireless cloud to the wired Ethernet. The data
   is place onto a high bandwidth wired backbone and routed to a
   central collection point, the Network Interface Facility (NIF.) The
   user's device then appears to the rest of the Internet as if it is
   physically located at the PPP termination point. 

Inamura, et. al.        Expires January 3, 2002                [Page 10]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks       July 2001

4. Open Issues

   Other ideas to enhance the performance of TCP over the 2.5G/3G
   networks may include the ROHC (RObust Header Compression) for TCP
   [18], RFC2309[17] (Active Queue Management). 

   We have been interested in T/TCP (Transaction/TCP), RFC1644[16],
   because the Web browsing on a smart phone tends to require short TCP
   connection duration and small amount of data transfer. The pattern
   of such use is more transactional rather than streaming. Because
   T/TCP is regarded as being weak security-wise [35], and not widely
   deployed, we did not recommend T/TCP in this document. 

   Experimental RFC2414[5] describes a mechism for using intial values
   of CWND greater than 2. This approach has not yet been proven safe
   for widespread use in the Internet. However, implementers are
   encouraged monitor research in this area (for example [15]) because
   larger initial values for CWND will reduce the time it takes to
   perform TCP data transfers. 

   Eifel algorithm [19] is an enhancement to TCP's error recovery
   scheme. It eliminates the retransmission ambiguity, thereby solving
   the problems caused by spurious timeouts and spurious fast
   retransmits. It is promising for wireless networks where spurious
   retransmissions may occur, the algorithm can improve the end-to-end
   throughput, because it reduces the penalty of a spurious timeout to
   a single (in the common case) spurious retransmission. 

   D-SACK (Duplicated SACK), RFC2883[29], specifies how to use the SACK
   option when acknowledging duplicate segments. Using D-SACK, sender
   can know what order the segments arrived and infer more precisely
   the cause for the situations where duplicate packets received,
   including early retransmit timeout. Because the delay-jitter seen in
   the 2.5G/3G networks may cause such early retransmit timeout, this
   extension can be useful for adjusting the RTO calculation to reduce
   the case of spurious retransmissions. 

   We should watch more evaluation and deployment/standardization
   status of Eifel and D-SACK in the wireless environment. 

   RFC2988[37] specifies standard algorithm to use to compute the
   retransmit timer in TCP. The RFC states that the TCP sender should
   set the initial RTO value less than three seconds. To avoid spurious
   time out in very first exchange of packets, subnetwork
   designer/operator should be carefull about the link layer behavior.
   The use of highly persistant ARQ and multiple hop of such links in
   the end-to-end path may result in too large delay. In general,
   subnetwork designers should minimize all three parameters delay,
   delay variance and packet loss) as much as possible [12]. 

Inamura, et. al.        Expires January 3, 2002                [Page 11]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks       July 2001

5. Security Considerations

   In 2.5G/3G wireless network, data transmission in ciphertext is
   limited only over the air, but cleartext between RAN and core
   network. 

   For the end to end security, IP security RFC2411[33] or TLS
   RFC2246[32] could be deployed. 

   If you use the transport gateway as mentioned in Section 3.1.2, note
   that it introduces several issues which impact security, which
   includes the conflict with IPsec. 

   For example, WAP protocol stack is considering to deploy TLS [31]
   because of its gateway architecture. 

Inamura, et. al.        Expires January 3, 2002                [Page 12]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks       July 2001

References

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

   [2]   Third Generation Partnership Project, "3GPP Specifications",
         1999, 
         <http://www.3gpp.org/3G_Specs/3G_Specs.htm>.

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

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

   [5]   Allman, M., Floyd, S. and C. Partridge, "Increased TCP's
         Initial Window", RFC 2414, September 1998.

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

   [7]   Allman, M., "An Evaluation of TCP with Larger Initial Windows
         40th IETF Meeting -- TCP Implementations WG. December",
         December 1997.

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

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

   [10]  Fairhurst, G. and L. Wood, "Link ARQ issues for IP traffic",
         Internet draft , November 2000, 
         <http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-arq-i
         ssues-00.txt>.

   [11]  Dawkins, S. and G. Montenegro, "End-to-end Performance
         Implications of Slow Links", Internet draft , November 2000, 
         <http://www.ietf.org/internet-drafts/draft-ietf-pilc-slow-05.tx
         t>.

   [12]  Karn, P., Falk, A., Touch, J., Montpetit, M., Mahdavi, J.,
         Montenegro, G., Grossman, D. and G. Fairhurst, "Advice for
         Internet Subnetwork Designers", Internet draft , November
         2000, 
         <http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-desig
         n-04.txt>.

Inamura, et. al.        Expires January 3, 2002                [Page 13]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks       July 2001

   [13]  Dawkins, S., Montenegro, G., Magret, V., Vaidya, N. and M.
         Kojo, "End-to-end Performance Implications of Links with
         Errors", Internet draft , November 2000, 
         <http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-06.t
         xt>.

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

   [15]  Allman, M., "A Web Server's View of the Transport Layer", ACM
         Computer Communication Review 30(5), October 2000, 
         <http://roland.grc.nasa.gov/~mallman/papers/webobs-ccr.ps>.

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

   [17]  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.

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

   [19]  Ludwig, R. and R. H. Katz, "The Eifel Algorithm: Making TCP
         Robust Against Spurious Retransmissions", ACM Computer
         Communication Review 30(1), January 2000, 
         <http://iceberg.cs.berkeley.edu/papers/Ludwig-Eifel-Alg/index.h
         tml>.

   [20]  Wireless Application Protocol, "WAP Wireless Profiled TCP", 
         WAP-225-TCP-20010331-p, April 2001, 
         <http://www.wapforum.com/what/review.htm#Proposed>.

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

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

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

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

   [25]  Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit

Inamura, et. al.        Expires January 3, 2002                [Page 14]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks       July 2001

         Congestion Notification (ECN) to IP", RFC 2481, January 1999.

   [26]  FCC Rules and Regulations, "Part 15", October 1997.

   [27]  NTT DoCoMo, Inc., "i-mode", 2001, 
         <http://www.nttdocomo.com/i/index.html>.

   [28]  NTT DoCoMo, Inc., "FOMA", 2001, 
         <http://foma.nttdocomo.co.jp/english/>.

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

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

   [31]  Wireless Application Protocol, "WAP TLS Profile and
         Tunneling",  WAP-219-TLS-20010411-p, May 2001, 
         <http://www.wapforum.com/what/review.htm#Proposed>.

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

   [33]  Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document
         Roadmap", RFC 2411, November 1998.

   [34]  Mitzel, D., "Overview of 2000 IAB Wireless Internetworking
         Workshop", RFC 3002, December 2000.

   [35]  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, 
         <http://www.acm.org/sigcomm/ccr/archive/1999/jan99/ccr-9901-dev
         ivo.html>.

   [36]  Border, J., Kojo, M., Griner, J., Montenegro, G. and Z.
         Shelby, "Performance Enhancing Proxies Intended to Mitigate
         Link-Related Degradations", Internet draft , May 3 2001, 
         <http://www.ietf.org/internet-drafts/draft-ietf-pilc-pep-07.txt
         >.

   [37]  Paxson, V. and M. Allman, "IP Security Document Roadmap", RFC
         2988, November 2000.

Inamura, et. al.        Expires January 3, 2002                [Page 15]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks       July 2001

Authors' Addresses

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

   EMail: [email-masked]
   URI:   http://www.nttdocomo.co.jp/

   Gabriel Montenegro
   Sun Microsystems, Inc.

   EMail: [email-masked]

   Max Hata
   NTT DoCoMo, Inc.

   EMail: [email-masked]
   URI:   http://www.nttdocomo.co.jp/

   Masahiro Hara
   Fujitsu, Inc.

   EMail: [email-masked]

   Joby James
   Motorola, Inc.
   33-A, Ulsoor Road,
   Bangalore  560042
   India

   EMail: [email-masked]

   William Gilliam
   Hewlett-Packard Company
   Cupertino, California

   EMail: [email-masked]

Inamura, et. al.        Expires January 3, 2002                [Page 16]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks       July 2001

   Alan Hameed
   Fujitsu FNC, Inc.

   EMail: [email-masked]

   Reiner Ludwig
   Ericsson Research
   Ericsson Allee 1
   52134 Herzogenrath
   Germany

   EMail: [email-masked]

   Rodrigo Garces
   Metricom

   EMail: [email-masked]

   Peter Ford
   Microsoft

   EMail: [email-masked]

   Fergus Wills
   Openwave

   EMail: [email-masked]

Inamura, et. al.        Expires January 3, 2002                [Page 17]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks       July 2001

Appendix A. Acknowledgements

   The authors gratefully acknowledges the valuable advises from
   following individuals: 

      Gorry Fairhurst ([email-masked])

      Mark Allman ([email-masked])

      Aaron Falk ([email-masked])

Inamura, et. al.        Expires January 3, 2002                [Page 18]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks       July 2001

Full Copyright Statement

   Copyright (C) The Internet Society (2001). 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.        Expires January 3, 2002                [Page 19]