Subject: [tcpm] upcoming consensus call on IW10

From: Jerry Chu <[email-masked]>
Date: Mon, 6 Jun 2011 04:53:34 -0700

Folks,

It's been a while since our last IW related discussion/debate, and
it's getting close for the WG to decide on the status of our IW10
proposal at the upcoming meeting in Quebec City. To get ready for
a consensus call, we have produced a major revision of the draft to
include all the up-to-date information for your peruse below.

We believe our IW10 proposal is ready for standardization now,
considering the following facts:

1. We have been experimenting with IW10 in a very large scale for
more than 9 months by now, and have observed its positive performance
impact consistently with no issue reported so far.

2. We have conducted a number of testbed studies to address concerns,
mainly on IW10's impact on slow links or other flows with smaller
IW. All the results show little or no negative impact from IW10, with
the only exception being some extreme overload cases where both IW10
and IW3 perform terribly. The full testbed results can be found at
http://research.csc.ncsu.edu/netsrv/?q=content/iw10

3. An informal poll by Mark Allman early this year seemed to show
the majority of people responding to the poll favored a simple,
static increase of IW right away.

4. The latest Linux kernel has adopted 10 as the default initial
congestion window size.

Once again, we believe a modest, static increase of IW to 10 is the
best, simplest, timely solution to a serious web performance problem
with little downside. We appreciate the value of two other related
proposals by M. Allman and J. Touch respectively, but believe, due
to their complexity (especially the one by Joe), they are best suited
for experiemental (e.g., likely need to refine the suggested formula),
and will best serve to carve out a growh path for IW beyond 10.

Comments and suggestions on how to move things forward are welcomed.
Also a complete set of IW10 related papers and past presentations
can be found at http://code.google.com/speed/protocols/tcpm-IW10.html

Best,

Jerry on behalf of all co-authors

On Thu, Apr 14, 2011 at 6:00 PM, <[email-masked]> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF.
>
>
>        Title           : Increasing TCP's Initial Window
>        Author(s)       : J. Chu, et al.
>        Filename        : draft-ietf-tcpm-initcwnd-01.txt
>        Pages           : 20
>        Date            : 2011-04-14
>
> This document proposes an increase in the permitted TCP initial
> window (IW) from between 2 and 4 segments, as specified in RFC 3390,
> to 10 segments. 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 risking congestion collapse. The document closes
> with a discussion of a list of concerns, and some results from recent
> studies to address the concerns.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-initcwnd-01.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Mark Allman <[email-masked]>
Date: Mon, 06 Jun 2011 09:07:47 -0400

> >        Filename        : draft-ietf-tcpm-initcwnd-01.txt

(1) We should Make This So.  

    Nobody has offered any illustrations of concrete and broad problems
    caused by this and to the contrary we have quite a bunch of evidence
    that addresses the concerns that have been raised.

    There is always One More Case that might be problematic, but we have
    been down that road quite a bit and seemingly things are OK.

    There is always some ratty network that will end up being
    problematic, but we should not hold everyone up based on corner
    cases. 

    The bottom line is that we will **never** **know** how it will work
    in the whole Internet until we deploy it in the actual whole
    Internet.

    So, I think unless someone can readily identify issues via concrete
    experiments and/or measurements that suggest this is a bad idea that
    the time has come to agree this is a reasonable path.

(2) I prefer a solution that does not specify an initial window, but
    rather a tolerance for problems caused by an initial window.  I
    think we should still move something like this forward so we don't
    ever have to consider a precise IW value again.  But, at this point
    it seems we should not hold up an IW bump for something that might
    or might not happen and has shown somewhat variable energy behind
    it.

allman