Increasing Maximum Window Size of TCP
draft-nishida-tcpm-maxwin-02
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Yoshifumi Nishida , Hirochika Asai | ||
| Last updated | 2016-10-30 | ||
| Stream | (None) | ||
| Formats | plain text xml htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-nishida-tcpm-maxwin-02
Network Working Group Y. Nishida
Internet-Draft GE Global Research
Intended status: Experimental H. Asai
Expires: May 3, 2017 The University of Tokyo
October 30, 2016
Increasing Maximum Window Size of TCP
draft-nishida-tcpm-maxwin-02.txt
Abstract
This document proposes to increase the current max window size
allowed in TCP. It describes the current logic that limits the max
window size and provides a rationale to relax the limitation as well
as the negotiation mechanism to enable this feature safely.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on May 3, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Nishida & Asai Expires May 3, 2017 [Page 1]
Internet-Draft Increase Maxwin October 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 2
3. Increasing Maximum Window Size . . . . . . . . . . . . . . . 2
4. Usage for New Shift Count . . . . . . . . . . . . . . . . . . 4
5. Use Cases, Benefits to Explore Maximum Window Size . . . . . 4
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
9.1. Normative References . . . . . . . . . . . . . . . . . . 5
9.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
TCP throughput is determined by two factors: Round Trip Time and
Receive Window size. It can never exceed Receive Window size divided
by RTT. This implies larger window size is important to achive
better performance. Original TCP's maximum window size defined in
RFC793 [RFC0793] is 2^16 -1 (65,535), however, RFC7323 [RFC7323]
defines TCP Window Scale option which allows TCP to use larger window
size. Window Scale uses a shift count stored in 1-byte field in the
option. The receiver of the option uses left-shifted window size
value by the shift count as actual window size. When Window Scale is
used, TCP can extend maximum window size to 2^30 - 2^14
(1,073,725,440). This is because the maximum shift count is 14 as
described in the Section 2.3 of RFC7323 [RFC7323]. However, since
TCP's sequence number space is 2^32, we believe it is still possible
to use larger window size than this while careful design of the logic
that can identify segments inside the window is required. In this
document, we propose to increase the maximum shift count to 15, which
extend window size to 2^31 - 2^15.
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Increasing Maximum Window Size
RFC7232 requires maximum window size to be less than 2^30 as
described below.
Nishida & Asai Expires May 3, 2017 [Page 2]
Internet-Draft Increase Maxwin October 2016
"
TCP determines if a data segment is "old" or "new" by testing whether
its sequence number is within 2^31 bytes of the left edge of the
window, and if it is not, discarding the data as "old". To insure
that new data is never mistakenly considered old and vice versa, the
left edge of the sender's window has to be at most 2^31 away from the
right edge of the receiver's window. The same is true of the
sender's right edge and receiver's left edge. Since the right and
left edges of either the sender's or receiver's window differ by the
window size, and since the sender and receiver windows can be out of
phase by at most the window size, the above constraints imply that
two times the maximum window size must be less than 2^31, or
max window < 2^30
"
However, TCP does not necessarily need to determine if a segment is
old or new. Because important point is to determine if a receive
segment is inside of the window or not. It basically does not matter
if a segment is too old (left side of the window) or too new (right
side of the window) as long as it is outside of the window. Based on
this viewpoint, we propose to extend maximum window to 2^31 - 2^15,
which can be attained by increasing maximum shift count to 15.
To demonstrate the feasibility of the proposal, we would like to use
the following worst case example where the sender and the receiver
windows are completely out of phase. In this example, we define S as
the sender's left edge of the window and W as the sender's window
size. Hence, the sender's right edge of the window is S+W. Also,
the receiver's left edge of the window is S+W+1 and the right edge of
the window is S+2W+1, as they are out of phase. This situation can
happen when the sender sent all segments in the window and the
receiver received all segments while no ACK has been received by the
sender yet. Now, we presume a segment that contains sequence number
S has arrived at the receiver. This segment should be excluded by
the receiver, although it can easily happen when the sender
retransmits segments.
In case of W=2^31, the receiver cannot exclude this segment as S+2W =
S. It is considered inside of the window. (S+W+1 < S < S+2W+1)
However, our proposed window size is W=2^31-X, where X is 2^15. In
this case, when segment S has arrived, the following checks will be
performed. First, TCP checks it with the left edge of the window and
it considers the segment is left side of the left edge. (S < S+W+1
Note: W=2^31-X) Second, TCP checks it with the right edge of the
window and it considers the segment is right of the right edge. (S >
S+2W+1) You might notice that the result of the second check is not
expected one as the segment S is actually an old segment. This is
Nishida & Asai Expires May 3, 2017 [Page 3]
Internet-Draft Increase Maxwin October 2016
the problem that the referred paragraphs from RFC7232 [RFC7323]
describe. However, the segment is properly excluded by the receiver
as both checks indicate it is outside of the window. It should be
noted that the principle of TCP requires to accept the segment S only
when it has passed both checks successfully, which means S must
satisfy the following condition.
S >= left edge && S <= right edge
As we have shown in the example, our proposed maximum window size:
W=2^31-2^15 does not affect this principle.
4. Usage for New Shift Count
In this proposal, an endpoint that supports new maximum window size
simply sets 15 to the shift count in Window Scale option. A
potential problem of this approach is that an endpoint cannot verify
if the peer supports shift count 15 unless the peer also uses shift
count 15. However, we believe this is not a significant problem. As
specified in [RFC7323], if an endpoint does not support shift count
15, it simply interprets it as shift count 14. while the window size
used by the sender will be smaller than the actual available window
size at the receiver, this will not cause any fatal issues
In order to avoid the performance degradation caused by
misinterpretation of shift count, an endpoint MAY allocate more than
65535 * 2^15 + 65535 * 2^14 bytes memory for connections that use
shift count 15. In this case, the endpoint that supports shiftcount
15 can always offer maximum window value and shift count 15 when the
peer does not support new shift count. Because the maximum window
value conventional endpoint can consume is 65535 * 2^14 bytes. As
long as an endpoint can offer shift count 15 with maximum window
value, conventional endpoints won't have performance issue.
5. Use Cases, Benefits to Explore Maximum Window Size
One of the use cases of the extended maximum window size is high
volume data transfer over paths with long RTT delays and high
bandwidth, called long fat pipes. The proposed extension improves
and doubles at most the maximum throughput when bandwidth-latency
product is greater than 1 GB. As propagation delay in an optical
fiber is around 20 cm/ns, RTT will be over 100 milliseconds when the
distance of the transmission is more than 10000km. This distance is
not extraordinary for trans-pacific communications. In this case,
the maximum throughput will be limited to 80 Gbps with the current
maximum window size, although network technologies for more than 100
Gbps are becoming common these days.
Nishida & Asai Expires May 3, 2017 [Page 4]
Internet-Draft Increase Maxwin October 2016
As the current TCP sequence number space is limited to 32 bits, it
will not be possible to increase maximum window size any further.
However, TCP may eventually have other extensions to increase
sequence number space, for example, [RFC7323] and [RFC1263] mention
about increasing sequence number space to 64 bits. We believe the
information in this document will be useful when such extensions are
proposed as they need to define new maximum window size.
6. Acknowledgments
The authors gratefully acknowledge significant inputs for this
document from Richard Scheffenegger and Ilpo Jarvinen.
7. Security Considerations
It is known that an attacker can have more chances to insert forged
packets into a TCP connection when large window size is used. This
is not a specific problem of this proposal, but a generic problem to
use larger window. Using PAWS can mitigate this problem, however, it
is recommended to consult the Security Considerations section of
RFC7323 [RFC7323] to check its implications.
8. IANA Considerations
This document does not create any new registries or modify the rules
for any existing registries managed by IANA.
9. References
9.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
Scheffenegger, Ed., "TCP Extensions for High Performance",
RFC 7323, DOI 10.17487/RFC7323, September 2014,
<http://www.rfc-editor.org/info/rfc7323>.
Nishida & Asai Expires May 3, 2017 [Page 5]
Internet-Draft Increase Maxwin October 2016
9.2. Informative References
[RFC1263] O'Malley, S. and L. Peterson, "TCP Extensions Considered
Harmful", RFC 1263, DOI 10.17487/RFC1263, October 1991,
<http://www.rfc-editor.org/info/rfc1263>.
Authors' Addresses
Yoshifumi Nishida
GE Global Research
2623 Camino Ramon
San Ramon, CA 94583
USA
Email: nishida@wide.ad.jp
Hirochika Asai
The University of Tokyo
7-3-1 Hongo
Bunkyo-ku, Tokyo 113-8656
JP
Email: panda@wide.ad.jp
Nishida & Asai Expires May 3, 2017 [Page 6]