idnits 2.17.1 draft-kim-tsvwg-butrigger-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 6) being 83 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 30 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2004) is 7376 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2581 (ref. 'APS99') (Obsoleted by RFC 5681) ** Obsolete normative reference: RFC 793 (ref. 'Pos81') (Obsoleted by RFC 9293) Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF TSVWG Working Group 3 Internet Draft Killyeon Kim 4 Youngjun Park 5 Kyungjoo Suh 6 Yongseok Park 7 Document: draft-kim-tsvwg-butrigger-00.txt Samsung 8 Electronics 9 Expires: August 2004 February 2004 11 The BU-trigger method for improving 12 TCP performance over Mobile IPv6 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 In Mobile IPv6 environment, TCP connections between MN (mobile node) 36 and CN (correspondent node) suffer a significant degradation in 37 performance in the form of poor throughput and very high interactive 38 delays during handoff. This note describes an optional modification 39 of TCP's congestion control mechanism for performance enhancement by 40 using Binding Update messages to invoke TCP's congestion control 41 processing. This modification is applied to TCP of CN side, and no 42 additional processing requirement is added to MN to save MN's power. 44 Conventions used in this document 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC-2119. 50 Table of Contents 52 1. Introduction...................................................2 54 2. Overview of BU-trigger Mechanism...............................3 56 3. Operation of BU-trigger Mechanism..............................4 58 3.1. Mobile IPv6 Extension for BU-trigger Mechanism............4 60 3.2. TCP Extension for BU-trigger Mechanism...........5 62 4. Interoperability with Mobile IPv6/TCP..........................5 64 References........................................................6 66 Author's Addresses................................................6 68 1. Introduction 70 Most of Internet services such as E-mail, ftp, and WWW employ TCP 71 (Transmission Control Protocol) as their transport protocol. It is 72 known that TCP is a reliable transport protocol tuned to perform well 73 in traditional networks made up of wired links and stationary hosts. 75 With the development of the wireless communication and Internet 76 services, wireless networking is facing a rapidly growing need for 77 efficient communication mechanisms that functionally integrate 78 wireless and wired Internet components across their varying and 79 distinctive transmission characteristics. Compared to wired networks, 80 a wireless link has much less bandwidth. In addition, a wireless link 81 has higher bit error rate due to its vulnerability to interference 82 and disconnection. Therefore packet loss in wireless networks 83 happens frequently and the response will take longer. 85 In such environment, TCP suffers a significant degradation in 86 performance in the form of poor throughput and very high interactive 87 delays. This behavior arises due to the fact that errors and handoffs 88 on the wireless links are incorrectly interpreted as congestion by 89 TCP at the sender. 91 This note proposes a mechanism called BU-trigger to recover the end- 92 to-end performance of TCP that is degraded during handoffs. The BU- 93 trigger mechanism aims to extend the functions of TCP and Mobile IPv6 94 protocols in CN side to improve the performance of TCP. 96 The BU-trigger mechanism is motivated by the followings: 98 (1) It increases the end-to-end performance of TCP without 99 modification of TCP/Mobile IPv6 protocols in MN side. 100 (2) It is interoperable with the original TCP/Mobile IPv6 protocol. 101 (3) No additional processing power consumption is added to MN side. 103 2. Overview of BU-trigger Mechanism 105 The BU-trigger mechanism is aimed to improve the end-to-end 106 performance of TCP in Mobile IPv6 environment. This method uses the 107 Binding Update messages which are sent from MN to CN to trigger TCP's 108 operation in CN side in order to recover performance degradation 109 during handoffs. 111 The BU-trigger method is aimed to recover cwnd (congestion window 112 size) of TCP connections which has been reduced to 1 because of 113 timeout in CN side to improve the performance of TCP [APS99]. The BU- 114 trigger extends Mobile IPv6 and TCP in CN side to achieve the 115 performance enhancement goal. In Mobile IPv6 layer, MN will send 116 Binding Update messages to CN to tell the new care-of-address when MN 117 moves to another domain. The valid binding update message received by 118 CN means handoff is over and CN can send packets to the MN. But 119 because handoff latency is longer than TCP's RTO (Retransmission 120 Timeout) in most of handoffs, the cwnd has been reduced. 122 The key point of BU-trigger mechanism is summarized as follows: 124 (1) Extension of Mobile IPv6 to generate BU-trigger signal to TCP 125 layer. 126 (2) Extension of TCP to remember the current congestion window size 127 (cwnd) and slow start threshold size (ssthresh) when timeout 128 occurs. 129 (3) Extension of TCP to recover the cwnd and ssthresh to the backup 130 values when TCP gets BU-trigger signal. 132 3. Operation of BU-trigger Mechanism 134 The BU-trigger mechanism is aimed to extend mobile IPv6 [Joh02] and 135 TCP [Pos81] functions in CN side. 137 Figure 1 shows the protocol stack of CN. The arrows in Figure 1 stand 138 for BU-trigger signal sent from Mobile IPv6 to TCP layer when CN gets 139 valid Binding Update messages. 141 +---------------------+ 142 | Application | 143 +---------------------+ 144 | TCP | 145 | ^ ^ ^ | 146 +-------+--+--+-------+ 147 | | | | | 148 | Mobile IPv6 | 149 + - - - - - - - - - - + 150 | IPv6 | 151 +---------------------+ 152 | MAC | 153 +---------------------+ 154 | PHY | 155 +---------------------+ 157 Figure 1 CN Protocol Stack 159 The operations of BU-trigger mechanism can be divided into Mobile 160 IPv6 part and TCP part. The extension functions of these parts will 161 be explained in the following sections. 163 3.1. Mobile IPv6 Extension for BU-trigger Mechanism 165 In Mobile IPv6 layer of CN side, the CN will perform some validation 166 checks before accepting a Binding Update. When CN accepts a valid 167 Binding Update, it will perform some extension functions needed by 168 the BU-trigger mechanism. 170 The operation of BU-trigger mechanism in Mobile IPv6 is as follows. 172 (1) Validate the Binding Update 173 (2) In the case of valid Binding Update, CN makes BU-trigger signal 174 according to the information in Binding Update. 175 (3) Invoke operation of TCP layer by sending BU-trigger signal to 176 TCP. 178 The trigger signal sent from MIPv6 to TCP layer should include MN's 179 home address because TCP layer needs to know which TCP connections 180 are related to the MN that sends Binding Update. TCP just need to 181 deal with the connections related to the current MN. 183 The method for delivering BU-trigger signal to TCP layer depends on 184 implementation. It can be delivered to TCP using IPC(Inter Process 185 Call) method, or it can be included in local delivery TCP packet. The 186 detailed description of BU-trigger signal contents and delivery 187 methods is out of the scope of this document. 189 3.2. TCP Extension for BU-trigger Mechanism 191 In order to recover TCP performance, we need to recover the 192 congestion window size(cwnd) and slow start threshold size(ssthresh) 193 to the values when retransmission timer is timeout because of handoff. 194 The BU-trigger mechanism adds previous cwnd (pcwnd) and previous 195 ssthresh (pssthresh) fields to the TCP transmission control block to 196 store previous cwnd and previous ssthresh. Moreover, every time the RTO 197 expires, the TCP will copy the current cwnd and ssthresh to pcwnd 198 and pssthresh. 200 The overall operation flow of BU-trigger mechanism in TCP layer is as 201 follows. 203 (1) When BU-trigger signal arrived, get the home IP address of the 204 MN. 205 (2) Check TCP's transmission control block entry by entry, if the 206 destination address of the entry is equal to MN's home IP 207 address, apply the following procedures: 208 (a) Recover the cwnd and ssthresh to pcwnd and pssthresh. 209 (b) Reset the RTO. 210 (c) Send the packets in sent_buffer. 212 Then, TCP in CN side will send packets with the rate before the 213 handoff occurs and the end-to-end performance of TCP will be recovered 214 quickly. 216 4. Interoperability with Mobile IPv6/TCP 218 The BU-trigger mechanism can be applied to Mobile IPv6 and TCP 219 protocol in CN side. The extension functions of Mobile IPv6 and TCP 220 due to BU-trigger mechanism have no effect to the TCP and Mobile 221 IPv6 behavior in normal nodes. In other words, the CN applied BU- 222 trigger mechanism will be interoperable well with hosts without BU- 223 trigger functions. 225 References 227 [APS99] M. Allman, V. Paxson, and W. Stevens. TCP Congestion Control. 228 RFC 2581, April 1999 230 [Pos81] J. Postel. Transmission Control Protocol. RFC 793, September 231 1981 233 [Joh02] D. Johnson, C. Perkins, and J. Arkko. "Mobility Support in 234 IPv6", draft-ietf-mobileip-ipv6-24.txt (work in progress) 236 Author's Addresses 238 Questions about this memo can be directed to: 240 Killyeon Kim 241 Samsung Electronics Co., Ltd. 242 Dong Suwon P.O.BOX 105 243 416 Maetan-3Dong, Youngtong-Gu, 244 Suwon-City, Gyeonggi-Do, Korea, 442-600 245 Email: kimkl@samsung.com 247 Youngjun Park 248 Global Standards and Strategy team 249 Telecommunication R & D Center 250 Samsung Electronics Co., LTD. 251 Dong Suwon P.O. BOX 105, 252 416, Maetan-3dong, Youngtong-gu, 253 Suwon-city, Gyeonggi-do, 442-600 254 Korea 255 Phone: +82-31-279-5979 256 Email: youngjun74.park@samsung.com 257 Fax: +82-31-279-5130 259 Kyungjoo Suh (Joo Suh) 260 Global Standards and Strategy team 261 Telecommunication R & D Center 262 Samsung Electronics Co., LTD. 263 Dong Suwon P.O. BOX 105, 264 416, Maetan-3dong, Youngtong-gu, 265 Suwon-city, Gyeonggi-do, 442-600 266 Korea 267 Phone: +82-31-279-5123 268 Email: joo.suh@samsung.com 269 Fax: +82-31-279-5130 271 Yongseok Park 272 Samsung Electronics Co., Ltd. 273 Dong Suwon P.O.BOX 105 274 416 Maetan-3Dong, Youngtong-Gu, 275 Suwon-City, Gyeonggi-Do, Korea, 442-600 276 Email: yougseok.park@samsung.com