Internet Engineering Task Force H. Inamura INTERNET DRAFT T. Ishikawa NTT DoCoMo, Inc 14 July 2000 A TCP profile for W-CDMA: 3G wireless packet service. draft-inamura-docomo-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Comments should be submitted to the PILC mailing list at pilc@grc.nasa.gov. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The third generation, 3G, wireless networks that enable high-speed data transfer are now being introduced. Internet access is one of the most important applications of such networks. TCP is one of the key technologies that enable Internet applications for such networks. A number of TCP optimization techniques have been studied to enhance the performance of TCP transmission for various wireless environments. Expires 14 January 2001 TCP/W-CDMA [Page 1] INTERNET DRAFT TCP profile for W-CDMA 14 July 2000 This document proposes a TCP profile that is a set of TCP features, derived from the previous studies in IETF, and is specifically effective for the use in W-CDMA (Wide-band CDMA) 3G wireless packet services. We conducted simulations to verify the performances of the profile. The features are discussed with the result of our simulation. We publish this memo to IETF for informational purpose, since there is no major modification to the IETF standard protocols. 1 Introduction IETF has been discussing performance enhancements to TCP for various wireless environments. The efforts are summarized in RFC2757 [LTN] that serves as a good survey for various options available for TCP. In order to define the most suitable TCP enhancements for the W-CDMA network, we have evaluated the options listed in the RFC based on our performance simulation, and compiled a profile of features for TCP that is a set of the options from the RFC and is effective in enhancing the performance of TCP over the W-CDMA network. In this document we propose the TCP profile for implementation guidelines and parameters for 3G W-CDMA wireless packet services for the Internet community. The list of features for the profile is small and conservative. Through the simulation, we confirmed that they work well under the 3G wireless packet service network environment. One of the important criteria for selecting the options is to ensure the interoperability with and minimal impact on existing TCP implementations. The profile consists of the following TCP options: * Choice of MTU size in link layer * Appropriate receive window size * Increased initial congestion window * Use of Selective ACK In the following sections, we introduce some of key aspects in W-CDMA infrastructure, and describe each of TCP features. 2 Architecture of W-CDMA packet service The architecture of W-CDMA is an implementation of 3GPP stan- dard[3GPP]. The W-CDMA network can accommodate high speed traffic up to 2Mbps (384kbps for best effort in the first deployment). Expires 14 January 2001 TCP/W-CDMA [Page 2] INTERNET DRAFT TCP profile for W-CDMA 14 July 2000 In the following section, we introduce an Internet-enabled mobile phone architecture and, then, we focus on the layer two ARQ and its impact on the TCP performance. 2.1 The architecture for Internet-enabled mobile phone on W-CDMA L7 |HTTP | |HTTP |HTTP | |HTTP | L4 | TCP | | TCP | TCP | | TCP | L3 | IP | | IP | IP | | IP | IP | | IP | L2 | RLC | | RLC |fiber| |fiber| any | | any | L1 |WCDMA| |WCDMA| any | | any | any | | any | Hand set BTS/RNC Gateway Web server Fig 1: The architecture of Internet-enabled mobile phone on W-CDMA As depicted in Fig. 1, The hand set is the browser equipped phone that talks TCP/IP. In BTS/RNC, IP traffic carried by the layer two ARQ over the air goes through the wire-line to the gateway. The gateway serves for the central point for call control to enable push functionality, charging and fire-walling, etc. 2.2 Layer two ARQ The key component in the W-CDMA network in terms of performance is the behavior of the layer two ARQ (L2 ARQ) protocol. The protocol, RLC (Radio Link Control) [RLC], is a kind of Selective Repeat ARQ. RLC defines PDU as its frame length to 336b (including 16b RLC header) that is the unit for retransmission. The SDU (in this compo- sition, IP packet) is fragmented into PDUs at RLC. The FEC (forward error correction) and interleaving is provided in the layer 1 ("WCDMA" in the Fig. 1). Two to twelve PDU (RLC frames) constitutes one FEC frame. The actual number of aggregation varies depending on the air condition and the allocation of bandwidth. The FEC frame is the unit of interleaving. The block error rate (BLER) is defined by the PDU (the unit of RLC frame) loss rate. The PDU loss becomes visible after interleave and the FEC are processed by the layer 1. RLC uses "status report" as an acknowledgment. It does not use sim- ple ack-clocking that is used by TCP, but it uses the poll bit in the header to explicitly solicit the peer for status report containing the sequence number that the peer acknowledged. The use of poll bit is controlled by timers and the size of available buffer space in RLC. Also, the peer can issue status report when it detects a gap Expires 14 January 2001 TCP/W-CDMA [Page 3] INTERNET DRAFT TCP profile for W-CDMA 14 July 2000 between sequence numbers in received frames, and it invokes retrans- mission. In summary, the RLC provides an almost error-free packet service to the upper layer traffic, i.e. IP. The SDU (IP packet) is fragmented into PDUs for RLC retransmission. The retransmission by RLC intro- duces latency and jitter to the SDU flow. 3 TCP profile for W-CDMA We have selected four features for TCP on W-CDMA. * Choice of MTU size in link layer * Appropriate receive window size * Increased initial congestion window * Use of Selective ACK To confirm the effects of these TCP features, we modeled the W-CDMA infrastructure into a simulation test bed running on OpNet [MIL3]. TCP/IP ----------queue---------------queue------------------TCP/IP RLC -[BLER]---RLC----[no loss]----Dedicated-[no loss]----Dedicated 442kbps(down) 384kbps line 1.5Mbps line 64kbps(up) Handset BTS/RNC Gate Switch Gateway/ Web server Fig 2: Simulation composition The attributes for each link is shown in Fig. 2. The two nodes, the BTS/RNC and the Gate Switch, each have a queues for speed adjustment. Without the queuing delay, we assumed 600ms latency from the Handset to the Gateway/Web server in roud trip, that is a realistic load sit- uation. The queuing delay and jitter are introduced by the simulated behavior of RLC under specific block error rate and pattern and TCP traffic. 3.1 Choice of MTU size in link layer One of the important link layer parameters is the MTU (Maximum Trans- fer Unit). In TCP, the slow start mechanism tries to find an ade- quate rate for the link layer. The larger MTU allows TCP to grow the congestion window faster, because the window is counted in unit of segments, especially when the link condition is good. In contrast, under a high BER situation, a smaller MTU is better in terms of the increased chance of successful transmission. With the L2 ARQ, the Expires 14 January 2001 TCP/W-CDMA [Page 4] INTERNET DRAFT TCP profile for W-CDMA 14 July 2000 upper layer can enjoy a larger MTU even in a relatively high BER con- dition. This is due to the result of trading a high BER with an increased latency, by the L2 ARQ. Due to the effect of the L2 ARQ, a large MTU and mss, such as 1500B, is recommended for the use with W- CDMA. In the following sections, we use 1500B MTU for the simulation parameter to discuss the performance. 3.2 Appropriate receive window size To utilize link capacity in full, a TCP sender has to send segments "on the fly". To achieve the maximum link efficiency for TCP, the advertised receive window size needs to be greater than the product of delay and bandwidth of the link. The link capacity varies by physical layers, even by specific wireless technologies. The receiver must advertise the appropriate receive window size to the link connected to. BLER\Rwin 32KB 64KB 128KB -------------------------------------------------------- 1e-2 340 kbps 369 kbps 369 kbps 5e-2 275 kbps 340 kbps 340 kbps 1e-1 230 kbps 320 kbps 320 kbps Table 1: TCP throughput with given BLER and receive window sizes. Table 1 shows the result of our simulation. It shows the TCP throughput for specific BLERs (block error rate) and receive window sizes. It models the transfer of 5MB data from a server to a W-CDMA handset. From the result, a receive window size of 64KB is recom- mended for the scenario of the simulation. 3.3 Increased initial congestion window TCP controls its transmit rate using the congestion window mechanism. In tradition, 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 [TCC]. This effectively cancels the delayed Ack by sending two seg- ments at once in the very first slow start turn. This contributes to avoiding the overhead in connection creation. Furthermore, the increased initial window option [IW] is also effec- tive especially for small data to be transmitted, which is commonly seen in such an application as the Internet-enabled mobile phone ser- vice. For large data transfer, on the other hand, the effect of this option is negligible. [All97] describes evaluations of this option Expires 14 January 2001 TCP/W-CDMA [Page 5] INTERNET DRAFT TCP profile for W-CDMA 14 July 2000 by simulation. According to our simulation, the increased initial window improves time to transfer 100KB by 2 second, reducing the time from 9 second to 7second. With RFC2414, contents around this size (more precisely, up to 4380B) can be transfered in one RTT just after the three-way handshake. Although RFC2414 is experimental status, there is no impact of using RFC2414 on the majority of the Internet as long as the gateway archi- tecture is used to limit the use of RFC2414 only between the handset and the gateway. Due to the fact that the delayed Ack mechanism is the standard and that the increased initial window option is especially effective for small data transfer that is common for such applications the i-mode service, this option is recommended. 3.4 Use of Selective ACK The Selective ACKnowledgement option (SACK) [SACK] is effective when multiple TCP segments are lost in a single TCP window. In particu- lar, if the link has a large delay-bandwidth product and a high packet loss rate, the ratio of multiple segment losses grows high. In such cases, SACK performs better than traditional and Reno TCP [FF96]. This is the case of 3G and SACK is recommended. As we see, the L2 ARQ handles the most of retransmission caused by wireless conditions. TCP retransmission occurs in window learning phase and due to the packets loss caused by bottle-neck routers. [FF96] shows the superiority of SACK and our simulation backs up this result. By setting the queue resource at the bottleneck router small (20 packets), that is simulating congestion situation, we see 20 sec- onds difference in time to transfer 1MB data. 40 seconds observed SACK is used for the transfer, while 60 seconds needed if Reno is used. 4. Summary and Conclusion In order to enable efficient TCP transport for 3G wireless packet service using W-CDMA, we have proposed a profile of TCP features, that is a set of TCP options derived from the previous works in IETF to enhance the performance of TCP in wireless environments. In selecting the features a special attention has been paid to ensure the interoperability with and minimal impact on existing TCP imple- mentations. We recognize that the proposed profile is small and con- servative. Expires 14 January 2001 TCP/W-CDMA [Page 6] INTERNET DRAFT TCP profile for W-CDMA 14 July 2000 Based on our simulation of the W-CDMA network, we have demonstrated and discussed the effectiveness of the profile. The features for the proposed TCP profile for W-CDMA are summarized in Table 2. Feature Parameter/Recommendation RFC/Status ------------------------------------------------------------------- MTU size 1500B N/A Window size 64KB RFC 793 Standard Initial window 2 mss RFC 2581 Proposed Standard Initial window up to 4380B RFC 2414 Experimental Use of SACK Recommend RFC 2018 Proposed Standard Table 2: Summary of implementation guidelines and parameters References [LTN] G. Montenegro, S. Dawkins, M. Kojo, V. Magret, N. Vaidya, "Long Thin Networks" RFC 2757, January 2000 [3GPP] http://www.3gpp.org [RLC] 3G TS 25.322: "RLC Protocol Specification" [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999 [MIL3] http://www.mil3.com [TCC] M. Allman, V. Paxson, W. Stevens, "TCP Congestion Control", RFC 2581, April 1999 [IW] M. Allman, S. Floyd, C. Partridge, "Increased TCP's Inital Window" RFC2414, September 1998 [All97] M.Allman, "An Evaluation of TCP with Larger Initial Windows", 40th IETF Meeting -- TCP Implementations WG. December 1997. [SACK] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, "TCP Selective Acknowledgment Options" RFC 2018, October 1996 [FF96] K.Fall, S.Floyd, "Simulation-based Comparisons of Tahoe, Reno, and SACK TCP," Computer Communication Review, 26(3), July 1996. Authors' Address Expires 14 January 2001 TCP/W-CDMA [Page 7] INTERNET DRAFT TCP profile for W-CDMA 14 July 2000 Hiroshi Inamura NTT DoCoMo, Inc. Multimedia Laboratories. 3-5 Hikarinooka Yokosuka-shi Kanagawa-ken 239-8536 Japan Phone: +81-468-40-3329 Fax: +81-468-40-3788 EMail: inamura@mml.yrp.nttdocomo.co.jp Taro Ishikawa NTT DoCoMo, Inc. Multimedia Laboratories. 3-5 Hikarinooka Yokosuka-shi Kanagawa-ken 239-8536 Japan Phone: +81-468-40-3033 Fax: +81-468-40-3788 EMail: taro@mml.yrp.nttdocomo.co.jp Appendix A DoCoMo's W-CDMA and background W-CDMA is one of the 3G wireless standards. NTT DoCoMo plans to use TCP as one of the core technologies to enable the wireless packet services. In order to achieve the high performance, we recognized that it is necessary to enhance the TCP performance for the W-CDMA environments. The W-CDMA network can accommodate high speed traffic up to 384kbps for best effort in the first deployment. The tariff is charged per packet basis. NTT DoCoMo plans to provide IP wireless packet services on W-CDMA (Wide-band CDMA) in Spring 2001, the next generation i-mode service over W-CDMA. Appendix B i-mode Since February 1999, NTT DoCoMo has been providing the "i-mode" ser- vice, that is a comprehensive mobile Internet service using Internet- enabled mobile phones, each equipped with a web browser in addition to the e-mail service and the digital mobile phone service. The num- ber of subscribers has exceeded 8 million in Japan, as of the date of submission, and is growing rapidly. The first generation of i-mode is implemented on top of the PDC (Per- sonal Digital Cellular) packet service using gateway architecture that acts as an HTTP proxy. NTT DoCoMo has evolved the PDC voice Expires 14 January 2001 TCP/W-CDMA [Page 8] INTERNET DRAFT TCP profile for W-CDMA 14 July 2000 cellular network into packet capable network by adding packet switches and routers. For the next generation i-mode service using the W-CDMA technology, we re-designed the network and made it into a much more IP-centric network, using the IPv4 addressing and routing technology. The traffic pattern specific to the NTT DoCoMo's i-mode service, size of an html page is limited to 5KB in the original phase. Although this limitation will be relaxed in the W-CDMA, we foresee such num- bers are still be the majority. When a user wants an end-to-end security solution, which is espe- cially needed for services such as on-line banking, the handset and the Web sever will communicate on TLS [TLS]. In that case, the gate- way only relays the TCP traffic. The profiled TCP that is proposed in this document will be imple- mented in the next generation of the i-mode service that will be a higher-transfer-rate wireless packet service enabled by the W-CDMA technology. Expires 14 January 2001 TCP/W-CDMA [Page 9]