Increasing TCP's Initial Window
draft-ietf-tcpm-initcwnd-08

[Ballot comment]
There's still a logic gap in the paragraph that resulted from this discussion, but I trust the authors and the area directors to work it out.

  It is important also to take into account hosts that do not implement
  a larger initial window. Furthermore, any deployment of IW10 should
  be aware that there are potential side effects to real-time traffic
  (such as VoIP). If users observe any significant deterioration of
  performance, they SHOULD fall back to an initial window as allowed by
  RFC 3390 for safety reasons. An increased initial window MUST NOT be
  turned on by default on systems without such monitoring capabilities.

This still seems to rely on the users of IW10 (specifically, the users of the hosts
that can change their behavior) noticing that their traffic is causing something
to go wrong between two other hosts that do not implement IW10. How is that
bit of magic going to happen on an IW10 host? They're only really going to be
able to monitor their _own_ real-time flows.

Better guidance would point to the operation environment - ideally, the operator of
the network would be able to monitor for the impact of this on flows between
hosts that aren't using IW10 and then work at human (rather than protocol) levels
to adjust the experiment if the impact is bad.

At the very least, please adjust the text to make it obvious that the potential impact
on real-time traffic goes beyond real-time traffic between the hosts using IW10.

[Ballot comment]
I'm pleased to see that you realized some experiments, and that you included the results in this document.
I'm with Adrian on his point:
  I would really like that Section 12 enhances...
      Further experiments are required before a larger initial window shall
      be enabled by default in the Internet.
      ...with...
      Larger window sizes MUST NOT be enabled by default in the Internet.

[Ballot discuss]
In my opinion, it's not appropriate to specify explicit changes to a PS
document in an Experimental document and show that the
Experimental document updates the PS document.  This document
is not making updates to the PS document that are to be added
to every implementation.

I will clear if the "Updates" metadata is dropped, and recommend that
some additional clarifying text be added that the modifications
described in this document may have a deleterious effect on other
Internet traffic and should be enabled only in controlled experiments.

[Ballot comment]

  Please consider the comments raised in the Gen-ART Review by
  Suresh Krishnan on 11-Dec-2012.  You can find the review here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07984.html

[Ballot comment]
I believe this is important work and I want to see the experimentation
progress, and feedback should be gathered to hopefully move this or
similar work onto the Standards Track.

So I am taking the peculiar position of balloting "Yes" while supporting
a Discuss from another AD.

---

I agree with Brian that this Experiment does not update 3390 and 5681,
but that were it to move to the Standards Track at some point, it would
update those RFCs.

I believe this is a simple editorial change.

---

I would really like that Section 12 enhances...
  Further experiments are required before a larger initial window shall
  be enabled by default in the Internet.
...with...
  Larger window sizes MUST NOT be enabled by default in the Internet.

[Ballot discuss]
(Based on a last call question from Magnus Westerlund)
Can the document point to studies on the impact on queue times
at intermediaries, and discuss how likely the transient spikes
in delays this might introduce are to become large enough to cause
real-time traffic to be held long enough to make its delivery
useless? (For many RTP uses, a packet that arrives too late is
discarded - the opportunity to render it has passed).

[Ballot comment]
Magnus asked several questions during last call that have not yet
received a response.

--

It's not clear how this safety requirement will actually help
in many circumstances:

  It is important also to take into account hosts that do not implement
  a larger initial window. Furthermore, non-TCP traffic (such as VoIP)
  should be monitored as well. If users observe any significant
  deterioration of performance, they SHOULD fall back to an initial
  window as allowed by RFC 3390 for safety reasons. An increased
  initial window MUST NOT be turned on by default on systems without
  such monitoring capabilities.

Does "systems" mean "hosts"? If so, the host using the larger initial
window is not going to see the harm its doing to its neighbor's real-time
streams? Or is the intent to restrict turning this on by default to hosts
in environements that have comprehensive (system) monitoring capabilities,
and the control mechanisms in place to affect the configuration of a host
when it is damaging its neighbors? Either way, please make the reqirement
more clear and be explicit about the limitations on how it will protect
real-time traffic.

--

In section 12, you require that a sender SHOULD cache information about whether
the larger initial window has created problems, and SHOULD not use the larger
window on new connnections that look like they might cause the same problems,
but then call out the design of such a cache (and the heuristic for whether a
new connection attempt will cause problems) as needing further experimentation.
That seems to reduce to "implementations SHOULD experiment".  Since this is an
experiment in the first place, why not make those MUSTs (or better, encourage
the experimentation with explicit prose?)

[Ballot discuss]
I  am happy to see this work progressing, but I have one concern that we should discuss...

I am troubled by seeing an Experimental document updating Standards Tracks RFCs (3390, 5681).  If the WG really believes this work will improve TCP, then it should be a Proposed Standard.  However, it is obvious that this proposal needs some experimentation to determine its fitness level.  Given that, I would propose that this document NOT update 3390 and 5681.  As Wes pointed out, we have precedence to allow a PS follow-on (if it is deemed useful) to this work to update the current standards track documents.  Quoting Wes:

"If we want to use the 2414 -> 3390 example of how this was
done in the past, 3390 updates the standards track (2581)
and is on the standards track itself.

2414 was its experimental predecessor and does not update
2001, which would have been the relevant standards track spec
at the time."

So, I would propose dropping the Updates metadata and explicitly mention in the body of the document those functions/features that differ from 3390 and 5681.

[Ballot discuss]
I  am happy to see this work progressing, but I have one concern that we should discuss...

I am troubled by seeing an Experimental document updating Standards Tracks RFCs (3390, 5681).  If the WG really believes this work will improve TCP, then it should be a Proposed Standard.  However, it is obvious that this proposal needs some experimentation to determine its fitness level.  Given that, I would propose that this document NOT update 3390 and 5681.  As Wes pointed out, we have precedence to allow a PS follow-on (if it is deemed useful) to this work to update the current standards track documents.  Quoting Wes:

"If we want to use the 2414 -> 3390 example of how this was
done in the past, 3390 updates the standards track (2581)
and is on the standards track itself.

2414 was its experimental predecessor and does not update
2001, which would have been the relevant standards track spec
at the time."

[Ballot comment]

- section 3, 2nd para says: "A larger initial window will
incentivize applications to use fewer concurrent TCP
connections." I don't see how that sentence follows from
those before it. Surely the logical conclusion from the
text so far is that browsers or other applications will
want to benefit from being (more) unfair to other
applications?

- section 12, para 2: would it be an idea to say that
implementers SHOULD provide a way to roll back deployment
of this change or that this is currently only suited for
applications where such a roll-back is possible?  You
already say implentations SHOULD monitor and turn this off
sometimes, but that's different, it could be that the
implementation cannot detect the problem and it could also
be that some applications are such that e.g. s/w update is
not widely supported for some reason (perhaps sensors that
use TCP or something).

- If there were a de-facto sockopt for turning this on or
off that might be useful to note.

- Would running over TLS affect any of the results cited?
Either way, that would be useful to note since there are
proposals that HTTP/2.0 have TLS always turned on.

- Just wondering:-) Has anyone considered whether or not
this might make DPI easier and/or interact with traffic
analysis of ciphertext? (I expect the answer to be "no"
but would be interested if not.)

IANA has reviewed draft-ietf-tcpm-initcwnd-06, which is currently in
Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Increasing TCP's Initial Window) to Experimental RFC


The IESG has received a request from the TCP Maintenance and Minor
Extensions WG (tcpm) to consider the following document:
- 'Increasing TCP's Initial Window'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-12-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document proposes an experiment to increase the permitted TCP
  initial window (IW) from between 2 and 4 segments, as specified in
  RFC 3390, to 10 segments, with a fallback to the existing
  recommendation when performance issues are detected. It discusses the
  motivation behind the increase, the advantages and disadvantages of
  the higher initial window, and presents results from several large
  scale experiments showing that the higher initial window improves the
  overall performance of many web services without resulting in a
  congestion collapse. The document closes with a discussion of usage
  and deployment for further experimental purpose recommended by the
  IETF TCP Maintenance and Minor Extensions (TCPM) working group.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/ballot/


No IPR declarations have been submitted directly on this I-D.

(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.