Skip to main content

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

Yes

(Martin Stiemerling)
(Wesley Eddy)

No Objection

(Barry Leiba)
(Gonzalo Camarillo)
(Pete Resnick)
(Ron Bonica)
(Sean Turner)

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

Adrian Farrel Former IESG member
Yes
Yes (2012-12-12 for -06) Unknown
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 Former IESG member
(was Discuss) Yes
Yes (2013-01-28 for -07) Unknown
Thanks for addressing my concerns.
Martin Stiemerling Former IESG member
Yes
Yes (for -06) Unknown

                            
Wesley Eddy Former IESG member
Yes
Yes (for -06) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (2012-12-13 for -06) Unknown
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.
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Ralph Droms Former IESG member
(was Discuss) No Objection
No Objection (2013-02-09 for -07) Unknown
Thanks for addressing my concerns; I've cleared my Discuss position.
Robert Sparks Former IESG member
(was Discuss) No Objection
No Objection (2013-02-25) Unknown
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.
Ron Bonica Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (2012-12-12 for -06) Unknown
  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
Sean Turner Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2012-12-10 for -06) Unknown
- 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.)
Stewart Bryant Former IESG member
No Objection
No Objection (2012-12-12 for -06) Unknown
I agree with the issues that Brian raises in his Discuss.