idnits 2.17.1 draft-nishida-tcpm-maxwin-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 30, 2017) is 2637 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Nishida 3 Internet-Draft GE Global Research 4 Intended status: Experimental H. Asai 5 Expires: August 3, 2017 The University of Tokyo 6 M. Bagnulo 7 UC3M 8 January 30, 2017 10 Increasing Maximum Window Size of TCP 11 draft-nishida-tcpm-maxwin-03.txt 13 Abstract 15 This document proposes to increase the current max window size 16 allowed in TCP. It describes the current logic that limits the 17 maximum window size and provides a rationale to relax the limitation 18 as well as the negotiation mechanism to enable this feature safely. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 3, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 2 56 3. Increasing Maximum Window Size . . . . . . . . . . . . . . . 3 57 4. Updating the Window Scale Option . . . . . . . . . . . . . . 4 58 5. Use Cases, Benefits to Explore Maximum Window Size . . . . . 5 59 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 64 9.2. Informative References . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 TCP throughput is determined by two factors: Round Trip Time and 70 Receive Window size. It can never exceed Receive Window size divided 71 by RTT. This implies larger window size is important to achieve 72 better performance. Original TCP's maximum window size defined in 73 RFC793 [RFC0793] is 2^16 -1 (65,535), however, RFC7323 [RFC7323] 74 defines TCP Window Scale option which allows TCP to use larger window 75 size. Window Scale uses a shift count stored in 1-byte field in the 76 option. The receiver of the option uses left-shifted window size 77 value by the shift count as actual window size. When Window Scale is 78 used, TCP can extend maximum window size to 2^30 - 2^14 79 (1,073,725,440). This is because the maximum shift count is 14 as 80 described in the Section 2.3 of RFC7323 [RFC7323]. However, since 81 TCP's sequence number space is 2^32, we believe it is still possible 82 to use larger window size than this while careful design of the logic 83 that can identify segments inside the window is required. In this 84 document, we propose to increase the maximum shift count to 15, which 85 extend window size to 2^31 - 2^15. 87 2. Conventions and Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 3. Increasing Maximum Window Size 95 RFC7323 requires maximum window size to be less than 2^30 as 96 described below. 98 " 99 TCP determines if a data segment is "old" or "new" by testing whether 100 its sequence number is within 2^31 bytes of the left edge of the 101 window, and if it is not, discarding the data as "old". To insure 102 that new data is never mistakenly considered old and vice versa, the 103 left edge of the sender's window has to be at most 2^31 away from the 104 right edge of the receiver's window. The same is true of the 105 sender's right edge and receiver's left edge. Since the right and 106 left edges of either the sender's or receiver's window differ by the 107 window size, and since the sender and receiver windows can be out of 108 phase by at most the window size, the above constraints imply that 109 two times the maximum window size must be less than 2^31, or 111 max window < 2^30 112 " 114 However, TCP does not necessarily need to determine if a segment is 115 old or new. Because important point is to determine if a receive 116 segment is inside of the window or not. It basically does not matter 117 if a segment is too old (left side of the window) or too new (right 118 side of the window) as long as it is outside of the window. Based on 119 this viewpoint, we propose to extend maximum window to 2^31 - 2^15, 120 which can be attained by increasing maximum shift count to 15. 122 To demonstrate the feasibility of the proposal, we would like to use 123 the following worst case example where the sender and the receiver 124 windows are completely out of phase. In this example, we define S as 125 the sender's left edge of the window and W as the sender's window 126 size. Hence, the sender's right edge of the window is S+W. Also, 127 the receiver's left edge of the window is S+W+1 and the right edge of 128 the window is S+2W+1, as they are out of phase. This situation can 129 happen when the sender sent all segments in the window and the 130 receiver received all segments while no ACK has been received by the 131 sender yet. Now, we presume a segment that contains sequence number 132 S has arrived at the receiver. This segment should be excluded by 133 the receiver, although it can easily happen when the sender 134 retransmits segments. 136 In case of W=2^31, the receiver cannot exclude this segment as S+2W = 137 S. It is considered inside of the window. (S+W+1 < S < S+2W+1) 138 However, our proposed window size is W=2^31-X, where X is 2^15. In 139 this case, when segment S has arrived, the following checks will be 140 performed. First, TCP checks it with the left edge of the window and 141 it considers the segment is left side of the left edge. (S < S+W+1 142 Note: W=2^31-X) Second, TCP checks it with the right edge of the 143 window and it considers the segment is right of the right edge. (S > 144 S+2W+1) You might notice that the result of the second check is not 145 expected one as the segment S is actually an old segment. This is 146 the problem that the referred paragraphs from RFC7323 [RFC7323] 147 describe. However, the segment is properly excluded by the receiver 148 as both checks indicate it is outside of the window. It should be 149 noted that the principle of TCP requires to accept the segment S only 150 when it has passed both checks successfully, which means S must 151 satisfy the following condition. 153 S >= left edge && S <= right edge 155 As we have shown in the example, our proposed maximum window size: 156 W=2^31-2^15 does not affect this principle. 158 Using the larger window size implies that the sequence number space 159 can wrap around in less than 3 RTTs. This can pose problems to 160 distinguish old retransmitted packets from new packets solely using 161 the same sequence number. Because of this, a sender using the larger 162 window size defined in this specification is recommended to use 163 Protection Against Wrapped Sequences (PAWS) as defined in RFC7323 164 [RFC7323]. 166 4. Updating the Window Scale Option 168 As shown in Figure 1, the Window Scale Option (WSO) defined in 169 [RFC7323] has three 1-byte fields, the Kind field (which specifies 170 the option type), the Length field (set to 3 because the WSO is 3 171 bytes long) and the shift.cnt field (which specifies the shift count 172 applied to the window to scale it). 174 +-----------+-----------+-----------+ 175 | Kind=3 | Length=3 | shift.cnt | 176 +-----------+-----------+-----------+ 177 1 1 1 179 Figure 1: Window Scale Option (WSO) format 181 RFC7323 [RFC7323] defines that the shift.cnt field can have a maximum 182 value of 14 and upon reception of a larger value in this field, the 183 receiver must proceed as if it had received a shift.cnt of 14. 185 This specification updates the shift.cnt field definition. Figure 2 186 represents the new format of the shift.cnt field. The eight bits 187 contained in the shift.cnt field are formatted as "SSSSLRRR". 189 0 1 2 3 4 5 6 7 190 +-+-+-+-+-+-+-+-+ 191 |S S S S L R R R| 192 +-+-+-+-+-+-+-+-+ 194 Figure 2: New shift.cnt field format 196 These bits are parsed as follows: 198 o The four leftmost bits "SSSS" express the shift-count, as in 199 RFC7323 [RFC7323], only that now the maximum shift count value 200 allowed is 15. 202 o The "L" bit expresses if the sender supports the large window 203 defined in this specification i.e. the bit is set if the sender 204 supports this specification. 206 o The three rightmost bits "RRR" are reserved for future use and 207 MUST be set to zero. 209 This new format for the shift.count field allows an updated client to 210 initiate a TCP connection and express that it supports the larger 211 window by setting the "L" bit, while still conveying information 212 about the shift count that it wants to use for its own RCV.WND in the 213 four leftmost bits "SSSS" (which do not necessarily have to be set to 214 15). A server that supports this specification that receives a SYN 215 with the WSO with the "L" bit set knows that it can reply using a 216 shift count of 15. A legacy server that receives the WSO with the 217 "L"" bit set will interpret it using the RFC7323 format and will then 218 read it as a shift count value larger than 14. As per RFC7323 the 219 server MUST then assume a shift count of 14. The legacy server will 220 then reply with a WSO with the "L" bit set to zero, so the client 221 knows that the server does not support this specification and that 222 the server will assume a shift count of 14 for the client's receive 223 window. 225 5. Use Cases, Benefits to Explore Maximum Window Size 227 One of the use cases of the extended maximum window size is high 228 volume data transfer over paths with long RTT delays and high 229 bandwidth, called long fat pipes. The proposed extension improves 230 and doubles at most the maximum throughput when bandwidth-latency 231 product is greater than 1 GB. As propagation delay in an optical 232 fiber is around 20 cm/ns, RTT will be over 100 milliseconds when the 233 distance of the transmission is more than 10000km. This distance is 234 not extraordinary for trans-pacific communications. In this case, 235 the maximum throughput will be limited to 80 Gbps with the current 236 maximum window size, although network technologies for more than 100 237 Gbps are becoming common these days. 239 As the current TCP sequence number space is limited to 32 bits, it 240 will not be possible to increase maximum window size any further. 241 However, TCP may eventually have other extensions to increase 242 sequence number space, for example, [RFC7323] and [RFC1263] mention 243 about increasing sequence number space to 64 bits. We believe the 244 information in this document will be useful when such extensions are 245 proposed as they need to define new maximum window size. 247 6. Acknowledgments 249 The authors gratefully acknowledge significant inputs for this 250 document from Richard Scheffenegger and Ilpo Jarvinen. 252 7. Security Considerations 254 It is known that an attacker can have more chances to insert forged 255 packets into a TCP connection when large window size is used. This 256 is not a specific problem of this proposal, but a generic problem to 257 use larger window. Using PAWS can mitigate this problem, however, it 258 is recommended to consult the Security Considerations section of 259 RFC7323 [RFC7323] to check its implications. 261 8. IANA Considerations 263 If approved, this document overrides the definition of the WSO option 264 defined in RFC7323 and so the IANA registry should be update 265 accordingly (at least to add a pointer to this specification as 266 reference for the WSO in the IANA registry). 268 9. References 270 9.1. Normative References 272 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 273 RFC 793, DOI 10.17487/RFC0793, September 1981, 274 . 276 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 277 Requirement Levels", BCP 14, RFC 2119, 278 DOI 10.17487/RFC2119, March 1997, 279 . 281 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 282 Scheffenegger, Ed., "TCP Extensions for High Performance", 283 RFC 7323, DOI 10.17487/RFC7323, September 2014, 284 . 286 9.2. Informative References 288 [RFC1263] O'Malley, S. and L. Peterson, "TCP Extensions Considered 289 Harmful", RFC 1263, DOI 10.17487/RFC1263, October 1991, 290 . 292 Authors' Addresses 294 Yoshifumi Nishida 295 GE Global Research 296 2623 Camino Ramon 297 San Ramon, CA 94583 298 USA 300 Email: nishida@wide.ad.jp 302 Hirochika Asai 303 The University of Tokyo 304 7-3-1 Hongo 305 Bunkyo-ku, Tokyo 113-8656 306 JP 308 Email: panda@wide.ad.jp 310 Marcelo Bagnulo 311 UC3M 313 Email: marcelo@it.uc3m.es