Increasing TCP's Initial Window
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: RFC Editor <firstname.lastname@example.org>, tcpm mailing list <email@example.com>, tcpm chair <firstname.lastname@example.org> Subject: Document Action: 'Increasing TCP's Initial Window' to Experimental RFC (draft-ietf-tcpm-initcwnd-08.txt) The IESG has approved the following document: - 'Increasing TCP's Initial Window' (draft-ietf-tcpm-initcwnd-08.txt) as Experimental RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Wesley Eddy and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/
Technical Summary: This document describes an experimental proposal to increase initial congestion window of TCP to at most 10 segments as well as a fall-back mechanism to limit any negative effects in limited buffer or bandwidth situations. It also provides guidelines to enable/disable this features in addition to some metrics to monitor the effect of this. Working Group Summary: There has been dominant opinions in the WG to increase initial window size of TCP. Question was whether we have a single updated value, or increasing the value gradually with a certain schedule, or defining a mechanics to adjust initial window size over time. We have explored several possibilities and eventually having a single updated value has become the consensus of the WG as other methods have some difficulties for large-scale deployment. Some of the approach in other methods have been merged into the draft during this process. The consensus was clear as no opinion against this proposal has been raised since then. Document Quality: Linux has already incorporated this proposal in the main kernel distribution. This document was reviewed by various people and has been discussed in the WG for nearly three years. The authors have provided results from their extensive experiments with a larger initial window. They also provided data to address questions and concerns by reviewers. In addition, there have been some related experiments by other TCPM contributors, mostly based on simulation. The document has been updated based on feedback from the community. I believe the authors did fairly extensive work for an experimental RFC, even if valid questions are still to be answered. The remaining questions, which need further experiments, are hard to address by the authors alone. Appendix A in the document contains the list for major discussion points of the draft. Personnel: Yoshifumi Nishida is the Document Shepherd for this document. The Responsible Area Director is Wesley Eddy. RFC Editor Note At the end of the 4th paragraph in section 12, please append: It is recognized that if IW10 is causing harm to other traffic, that this may not be readily apparent to the the software on the hosts using IW10. In some cases a local system or network administrator may be able to detect this, and to selectively disable IW10 in such cases. In the general case, however, since the harm may occur on a remote network, to other cross-traffic, there may be no good way at all for this to be detected or corrected. Current experience and analysis does not indicate whether this is a real issue, beyond a hypothetical one. As use of IW10 becomes more prevalent, monitoring and analysis of flows throughout the network will be needed to assess the impact across the spectrum of scenarios found on the real Internet.