[tcpm] publication request for draft-ietf-tcpm-initcwnd-06

[Yoshifumi Nishida <[e-mail]>]

Hello folks,

Publication request for iw10 has been sent to IESG.
I've attached the write-up for the draft below.

Thanks,
--
Yoshifumi

--------------------------------------------------------------------------------------------------------------------------
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?


   This document describes a proposal to increase initial window size of TCP
   at most 10 segments. As it is indicated in the title page header,
the consensus
   of the WG is to publish this document as an Experimental RFC.
   We will need further experiments for this proposal to be advanced
as described
   in Section 12.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or
introduction of the document. If not, this may be an indication that
there are deficiencies in the abstract or introduction.


   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:

Was there anything in WG process that is worth noting? For example,
was there controversy about particular points or were there decisions
where the consensus was particularly rough?


   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:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?


   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:

Who is the Document Shepherd? Who is the Responsible Area Director?

   Yoshifumi Nishida is the Document Shepherd for this document.
   The Responsible Area Director is Wesley Eddy.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

   I've reviewed the documents and made several editorial suggestions
in order to enhance the
   readability of the drafts. I believe the quality of this draft is
matured enough to be
   published.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

   I have no concern about it.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

   There is no need for particular reviews.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

   I have no concerns with the document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

   Yes, each authors has confirmed this.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

   No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

   The document is widely supported as we have seen positive comments
from various participants
   in the WG meetings as well as the ML. The consensus was solid and clear.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

   No one has indicated discontent.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

   ID nits gives the following errors and warnings. I've put my comments below.


   ** There is 1 instance of too long lines in the document, the longest one
       being 1 character in excess of 72.

   -> I think we can fix this through editing process


   -- The draft header indicates that this document updates RFC3390, but the
     abstract doesn't seem to directly say this.  It does mention RFC3390
     though, so this could be OK.

   -- The draft header indicates that this document updates RFC5681, but the
     abstract doesn't seem to mention this, which it should.

   -> I think these are minor points. As it is explained in the Introduction
     and the draft tries to update a rather minor portion of RFC3390
and RFC5681.


   == Unused Reference: 'RFC6077' is defined on line 844, but no explicit
     reference was found in the text

   -> It is referred in the text. This might be a bug for ID nits?

   -- Obsolete informational reference (is this intentional?): RFC 2414
     (Obsoleted by RFC 3390)

   -> This is intentional.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

   I believe no formal review is needed.

(13) Have all references within this document been identified as
either normative or informative?

   Yes.

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

   No.

(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

   No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

   This draft contains a proposal for adjusting initial window after
SYN, SYN/ACK
   retransmission, which will update RFC3390 and RFC5681. This is
described in the Abstract
   and Introduction and Section 2 explains the motivation.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

   The document does not involve any IANA considerations.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

   There is no need to require expert review for future allocations.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

   The document contains no formal language.