Increasing TCP's Initial Window
RFC 6928

Note: This ballot was opened for revision 06 and is now closed.

(Wesley Eddy) Yes

(Adrian Farrel) Yes

Comment (2012-12-12 for -06)
No email
send info
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.

(Brian Haberman) (was Discuss) Yes

Comment (2013-01-28 for -07)
No email
send info
Thanks for addressing my concerns.

(Martin Stiemerling) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2012-12-12 for -06)
No email
send info
I agree with the issues that Brian raises in his Discuss.

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2012-12-13 for -06)
No email
send info
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.

(Ralph Droms) (was Discuss) No Objection

Comment (2013-02-09 for -07)
No email
send info
Thanks for addressing my concerns; I've cleared my Discuss position.

(Stephen Farrell) No Objection

Comment (2012-12-10 for -06)
No email
send info
- 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.)

(Russ Housley) No Objection

Comment (2012-12-12 for -06)
No email
send info
  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

Barry Leiba No Objection

(Pete Resnick) No Objection

(Robert Sparks) (was Discuss) No Objection

Comment (2013-02-25)
No email
send info
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.

(Sean Turner) No Objection