Hewlett-Packard Company Motorola, Inc.

Network Working Group H. Inamura (editor) Internet-Draft NTT DoCoMo, Inc. Expires: August 23, 2001 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 Feb 22, 2001 TCP over 2.5G and 3G Wireless Networksdraft-ietf-pilc-2.5g3g-00Status of this MemoThis document is an Internet-Draft and is in full conformance withall provisions of Section 10 of RFC2026.Internet-Drafts are working documents of the Internet EngineeringTask Force (IETF), its areas, and its working groups. Note thatother groups may also distribute working documents asInternet-Drafts.Internet-Drafts are draft documents valid for a maximum of sixmonths and may be updated, replaced, or obsoleted by other documentsat any time. It is inappropriate to use Internet-Drafts as referencematerial or to cite them other than as "work in progress."The list of current Internet-Drafts can be accessed at/ietf/1id-abstracts.txt.The list of Internet-Draft Shadow Directories can be accessed at/shadow.html.Comments should be submitted to the PILC mailing list atpilc@.Distribution of this memo is unlimited.Inamura, et. al. Expires August 23, 2001 [Page 1]Internet-Draft TCP over 2.5G and 3G Wireless Networks Feb 2001 This Internet-Draft will expire on August 23, 2001.Copyright NoticeCopyright (C) The Internet Society (2001). All Rights Reserved. AbstractThis document describes a profile for optimizing TCP over 2.5G/3Gnetworks. We describe the link characteristics of 3G wireless byusing W-CDMA (Wideband CDMA) as an example. We then recommend TCPoptimization mechanisms and, finally, present examples of wirelessinternet services and standardization activities. These potentiallywill deploy the profile described in this document.Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 32. 2.5G and 3G Link Characteristics . . . . . . . . . . . . . . 43. 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 MTU larger than default IP MTU . . . . . . . . . . . . . . . 6 3.1.4 Path MTU discovery . . . . . . . . . . . . . . . . . . . . . 6 3.1.5 Selective Acknowledgments . . . . . . . . . . . . . . . . . 6 3.1.6 Explicit Congestion Notification . . . . . . . . . . . . . . 7 3.1.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Applications . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1 i-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.2 WAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2.3 Ricochet MCDN Network . . . . . . . . . . . . . . . . . . . 84. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 105. Security Considerations . . . . . . . . . . . . . . . . . . 11 References . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . 13 Full Copyright Statement . . . . . . . . . . . . . . . . . . 15 Inamura, et. al. Expires August 23, 2001 [Page 2]Internet-Draft TCP over 2.5G and 3G Wireless Networks Feb 2001 1. IntroductionRecently, much development and deployment activity has centeredaround GPRS, UMTS and IMT-2000, also referred to as 2.5G/3G wireless networks. Since a primary motivation for these is datacommunication, and, in particular, Internet access, TCP performanceis a key issue.A number of TCP optimization techniques have been studied to enhance the performance of TCP transmission for various wirelessenvironments.This document proposes a profile of such techniques, derived fromprevious work at the IETF, particularly effective for use with 2.5Gand 3G wireless networks.Inamura, et. al. Expires August 23, 2001 [Page 3]Internet-Draft TCP over 2.5G and 3G Wireless Networks Feb 2001 2. 2.5G and 3G Link CharacteristicsThe link layer characteristics of 2.5G/3G network affects TCPperformance over the link. The characteristics are layer two ARQ (L2 ARQ), FEC (forward error correction) and so on [1]. Thejustification 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 windowARQ. RLC uses protocol data units (PDUs) 336 bits long (including a16 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 FECframe depends on the link conditions and bandwidth allocation. TheFEC frame is the unit of interleaving.RLC uses "status report" type acknowledgments. It does not useack-clocking as in TCP, but rather the poll bit in the headerexplicitly solicits the peer for a status report containing thesequence number that the peer acknowledged. The use of the poll bitis controlled by timers and by the size of available buffer space in RLC. Also, when the peer detects a gap between sequence numbers inreceived frames, it can issue a status report invoke retransmission. The maximum number of retransmissions is a configurable RLCparameter, with a maximum value of 10. Therefore, RLC can bedescribed as an ARQ that can be configured in eitherHIGH-PERSISTENCE or LOW-PERSISTENCE, not PERFECTLY-PERSISTENT,according to the terminology in [10].In general, the L2 ARQ and FEC can provide an almost error-freepacket service to the upper layer traffic, i.e. IP. The SDU (IPpacket) is fragmented into PDUs for transmission. The retransmission by L2 ARQ introduces latency and jitter to the SDU flow, thatresults in relatively large BDP (Bandwidth-Delay Product) of the2.5G/3G networks.Inamura, et. al. Expires August 23, 2001 [Page 4]Internet-Draft TCP over 2.5G and 3G Wireless Networks Feb 2001 3. TCP over 2.5G and 3G3.1 Optimization Mechanisms3.1.1 Large window sizeTo utilize link capacity in full, a TCP sender has to send segmentsto "fill the pipe". To achieve the maximum link efficiency for TCP,the advertised receive window size needs to be equal to or greaterthan the BDP (Bandwidth Delay Product) of the end-to-end path.The wireless link capacity varies by specific technologies used. In2.5G/3G wireless, the link BDP tends to large. If the end-to-endpath contains one or more wireless link, the end-to-end BDP might be larger than the default value of receive window size on many TCPimplementations. 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 link capacity is expected to be larger than 64 KB, the window scale option [6] must be applied. TCP over 2.5G/3G SHOULD supportappropriate window sizes based on the BDP of the end-to-end path.For better round trip time estimates, timestamp option [6] isrecommended to be implemented when supporting window size of 64 KBand more. TCP over 2.5G/3G MAY support timestamp. If the window size is larger than or equal to 64KB, implementation SHOULD supporttimestamp option.3.1.2 Large initial windowTCP controls its transmit rate using the congestion windowmechanism. Traditionally, the initial value of the window is onesegment. Because the delayed Ack mechanism is widely deployed, a TCP sender should have an increased initial congestion window of twosegments[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 connection creation.Furthermore, the increased initial window option [5] is alsoeffective, especially for small data to be transmitted, which iscommonly seen in such an application as the Internet-enabled mobilewireless devices. For large data transfer, on the other hand, theeffect of this option is negligible. [7] describes evaluations ofthis option by simulation.Two segments of initial congestion window size is recommended in[4][5] also notes consideration on use of initial window size ofmore than two. Although the increased initial congestion window is Inamura, et. al. Expires August 23, 2001 [Page 5]Internet-Draft TCP over 2.5G and 3G Wireless Networks Feb 2001 experimental status, there is no impact of use of it to the majority of the Internet if the gateway architecture is deployed thatterminates TCP connection between the mobile node and the gateway.Due to the fact that the delayed Ack mechanism is the standard andthat 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 MUST use cwnd = 2. It MAY use cwnd > 2 if a gateway is present.3.1.3 MTU larger than default IP MTUOne of the link layer parameters is MTU (Maximum Transfer Unit). InTCP, the slow start mechanism tries to find an adequate rate for the link layer. The larger MTU allows TCP to grow the congestion windowfaster [11] , because the window is counted in unit of segments,especially when the link condition is good. In contrast, under ahigh BER (Bit Error Rate) situation, smaller MTU is better in termsof the chance of successful transmission. With layer two ARQ, theupper layer can enjoy larger MTU even in a relatively high BERcondition. Due to this tradeoff, TCP over 2.5G/3G SHOULD allowfreedom for designers to choose MTU from a small value (such as576B) to a large value (up to 1500B).3.1.4 Path MTU discoveryPath MTU discovery allows a sender to determine the maximumend-to-end transmission unit for a given routing path. [RFC1191] and [RFC1981] describe the MTU discovery procedure for IPv4 and IPv6respectively. This allows TCP senders to employ larger segment sizes (without causing fragmentation) instead of assuming the default MTU. Using larger segment sizes allows for a faster increase in thecongestion window and a smaller ratio of header overhead to data. It should be noted that larger MTUs increase the probability of errorin a given segment and also increase the packet transmission time.TCP over 2.5G/3G implementations SHOULD implement Path MTUDiscovery. Path MTU Discovery requires intermediate routers tosupport the generation of the necessary ICMP messages. [RFC1435]provides recommendations that may be relevant for some routerimplementations.3.1.5 Selective AcknowledgmentsThe selective acknowledgment option (SACK) [8] is effective whenmultiple TCP segments are lost in a single TCP window [13] . Inparticular, if the link has a large BDP and a certain amount ofpacket loss rate, the ratio of multiple segment losses grows high.In such cases, SACK performs better than traditional and Reno TCP[9]. TCP over 2.5G/3G MUST support SACK.Inamura, et. al. Expires August 23, 2001 [Page 6]Internet-Draft TCP over 2.5G and 3G Wireless Networks Feb 20013.1.6 Explicit Congestion NotificationExplicit Congestion Notification [RFC2481] allows a TCP receiver toinform the sender of congestion in the network by setting theECN-Echo flag; a receiver will set this flag on receiving an IPpacket marked with the CE bit. The TCP sender can then reduce itscongestion window. The use of ECN is believed to provide performancebenefits [RFC2884]. TCP over 2.5G/3G MAY support ECN. [RFC2481] alsoplaces requirements on intermediate routers (e.g. active queuemanagement and setting of the CE bit in the IP header to indicatecongestion). Thus the use of ECN on the TCP connections is dependenton the necessary support from the relevant routers.3.1.7 SummaryItems Qualifier Support------------------------------------------------------------------------- Large window size SHOULDbased on BDPWindow scale option Window size>64KB MUST[RFC1323]Timestamp option for RTTM Window size>64KB SHOULD[RFC1323]Large initial window (cwnd = 2) MUST[RFC2581]Large initial window (cwnd > 2) MAY[RFC2414]Selective Acknowledgment option (SACK) MUST[RFC2018]Path MTU discovery SHOULD[RFC1191,RFC1981]MTU larger than default IP MTU MAYExplicit Congestion Notification(ECN) MAY[RFC2481]3.2 ApplicationsWe introduce wireless services deploying (or capable of deploying)the recommendation we discuss here. Net-enabled portable phones andwireless ISPs are the two major applications.3.2.1 i-modeMobile terminal users want to enjoy the Internet experience on theirhandset. This market is emerging and growing rapidly. A deploymentexample is i-mode, a wireless Internet service. As of this writing,it is the largest single wireless internet service in the world,with 19 million subscribers in Japan.Inamura, et. al. Expires August 23, 2001 [Page 7]Internet-Draft TCP over 2.5G and 3G Wireless Networks Feb 2001 The next version of i-mode that operates over W-CDMA will belaunched at the end of May 2001. It will deploy the profiled TCPthat is described in this document. The browser embedded in thehandset will utilize the higher speed of 3G infrastructure that canprovide up to 384kbps packet mode service.From the perspective of transport layer, the underlying W-CDMAnetwork can be viewed as a network with a relatively large BDP andjitter. The loss rate of IP packets is low due to the ARQ, but therecovery 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 theembedded 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 datacommunication facilities can be controlled via AT modem commands.The W-CDMA infrastructure, whose core network uses GPRS (GeneralPacket Radio Service), can be viewed as a large PPP link to GGSN(Gateway GPRS Supporting Node). The other side of GGSN is connectedto fixed networks of ISPs using, for example, leased lines.3.2.2 WAPThe WAP Forum [14] is an industry association that has developedstandards for wireless information and telephony services on digital mobile phones and other wireless terminals. In order to address WAPfunctionalities for high speed networks such as 2.5G and 3G networks and to aim at convergence to the Internet standards, the WAP Forumhas 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 about to release a new generation of specifications for public review, subject to membership approval. These specificationsmay include the profiled TCP that is described in this submission.The WAP forum specification profiling TCP is expected to beavailable for public review in the March 2001 timeframe.3.2.3 Ricochet MCDN NetworkRicochet is a wide-area wireless packet data network. Thearchitecture for the Ricochet system is the MicroCellular DataNetwork (MCDN). 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 NameService; 6) a Network Management System; 7) and gateways. The MCDNsystem architecture is based on a mesh of MicroCells deployedthroughout a metropolitan area following the part 15.247 FCC rulesand regulations for the ISM band [1].Inamura, et. al. Expires August 23, 2001 [Page 8]Internet-Draft TCP over 2.5G and 3G Wireless Networks Feb 2001 After radios have acquired each other, they register with the NameService. The registration process allows the Name Service to storethe information required to route from the Name Server to theregistering entity. The Name Server can construct a route betweenthe two devices and return an MCDN path with enough information toallow packets to be routed between the two entities. Each deviceappends the MCDN path to any packet it wishes to route through thenetwork.The customer’s radio modem typically appears as a standard ATcommand-based modem. The modem sends a LookUp packet to the NameService asking for the MCDN path to the logical name, typically anMCDN gateway to the Internet or an intranet. The user’s device thencontinues to negotiate a PPP connection so that it can be assignedan IP address, an IP router, and a DNS server and become afull-fledged communicating member of the global Internet.When the user’s computing device is attempting to negotiate PPP toconnect to the network, the radio modem establishes a virtualconnection, analogous to TCP, to the MCDN gateway, which ensuresthat all of the packets from the user’s computing device get routedto the Internet via the MCDN gateway. The Wired Access Point placesthe wireless packets onto a high bandwidth wired backbone and routethem 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 August 23, 2001 [Page 9]Internet-Draft TCP over 2.5G and 3G Wireless Networks Feb 2001 4. Open IssuesOther ideas to enhance the performance of TCP over the 2.5G/3Gnetworks may include the use of T/TCP, ROHC for TCP, Active QueueManagement, Eifel Algorithm and so on.We have been interested in T/TCP because the Web browsing on a smart phone tends to require short TCP connection duration and smallamount of data transfer. The pattern of such use is moretransactional rather than streaming. Because T/TCP is regarded asbeing weak for attacks and not widely deployed, we did not recommend T/TCP in this document.In this document, RFC2414 is treated as an experimental status.RFC2414 is now up for reconsideration to become a proposed standard. Should it get approved as a proposed standard, we can drop therestriction that CWND=3 or 4 may only be used with gateway. Thereare some fairly recent results on using a larger initial cwnd in our web server in [15].Inamura, et. al. Expires August 23, 2001 [Page 10]Internet-Draft TCP over 2.5G and 3G Wireless Networks Feb 2001 5. Security ConsiderationsPlease note some of RFCs related to this discussion containsconsideration to security issues for example [4].Inamura, et. al. Expires August 23, 2001 [Page 11]Internet-Draft TCP over 2.5G and 3G Wireless Networks Feb 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,</3G_Specs/3G_Specs.htm>.[3] Third Generation Partnership Project, "RLC ProtocolSpecification (3G TS 25.322:)", 1999.[4] Allman, M., Paxson, V. and W. Stevens, "TCP CongestionControl", RFC 2581, April 1999.[5] Allman, M., Floyd, S. and C. Partridge, "Increased TCP’sInitial Window", RFC 2414, September 1998.[6] Jacobson, V., Bdaden, R. and D. Borman, "TCP Extensions forHigh Performance", RFC 1323, May 1992.[7] Allman, M., "An Evaluation of TCP with Larger Initial Windows40th IETF Meeting -- TCP Implementations WG. December",December 1997.[8] Mathis, M., Mahdavi, J., Floyd, S. and R. Romanow, "TCPSelective 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,</internet-drafts/draft-ietf-pilc-link-arq-i ssues-00.txt>.[11] Dawkins, S. and G. Montenegro, "End-to-end PerformanceImplications of Slow Links", Internet draft , November 2000,</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 forInternet Subnetwork Designers", Internet draft , November2000,</internet-drafts/draft-ietf-pilc-link-desig n-04.txt>.Inamura, et. al. Expires August 23, 2001 [Page 12]Internet-Draft TCP over 2.5G and 3G Wireless Networks Feb 2001 [13] Dawkins, S., Montenegro, G., Magret, V., Vaidya, N. and M.Kojo, "End-to-end Performance Implications of Links withErrors", Internet draft , November 2000,</internet-drafts/draft-ietf-pilc-error-06.t xt>.[14] Wireless Application Protocol, "WAP Specifications", 2000,<>.[15] Allman, M., "A Web Server’s View of the Transport Layer", ACMComputer Communication Review 30(5), October 2000,</˜mallman/papers/webobs-ccr.ps>. Authors’ AddressesHiroshi InamuraNTT DoCoMo, Inc.3-5 HikarinookaYokosuka Shi, Kanagawa Ken 239-8536JapanPhone: +81 468 40 3329EMail: inamura@mml.yrp.nttdocomo.co.jpURI: http://www.nttdocomo.co.jp/Gabriel MontenegroSun Microsystems, Inc.EMail: gab@Max HataNTT DoCoMo, Inc.EMail: hata@mml.yrp.nttdocomo.co.jpURI: http://www.nttdocomo.co.jp/Masahiro HaraFujitsu, Inc.EMail: mhara@FLAB.FUJITSU.CO.JPInamura, et. al. Expires August 23, 2001 [Page 13]Internet-Draft TCP over 2.5G and 3G Wireless Networks Feb 2001 Joby JamesMotorola, Inc.33-A, Ulsoor Road,Bangalore 560042IndiaEMail: joby@William GilliamHewlett-Packard CompanyCupertino, CaliforniaEMail: wag@Alan HameedFujitsu FNC, Inc.EMail: Alan.Hameed@Reiner LudwigEricsson ResearchEricsson Allee 152134 HerzogenrathGermanyEMail: Reiner.Ludwig@Rodrigo GarcesMetricomEMail: RGarces@Peter FordMicrosoftEMail: peterf@Fergus WillsOpenwaveEMail: fergus.wills@Inamura, et. al. Expires August 23, 2001 [Page 14]Internet-Draft TCP over 2.5G and 3G Wireless Networks Feb 2001 Full Copyright StatementCopyright (C) The Internet Society (2001). All Rights Reserved.This document and translations of it may be copied and furnished toothers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, publishedand distributed, in whole or in part, without restriction of anykind, provided that the above copyright notice and this paragraphare included on all such copies and derivative works. However, thisdocument itself may not be modified in any way, such as by removingthe copyright notice or references to the Internet Society or otherInternet organizations, except as needed for the purpose ofdeveloping Internet standards in which case the procedures forcopyrights defined in the Internet Standards process must befollowed, or as required to translate it into languages other thanEnglish.The limited permissions granted above are perpetual and will not berevoked 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 ENGINEERINGTASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDINGBUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATIONHEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OFMERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.AcknowledgementFunding for the RFC editor function is currently provided by theInternet Society.Inamura, et. al. Expires August 23, 2001 [Page 15]。