Re: [tcpm] I-D Action:draft-hkchu-tcpm-initcwnd-00.txt

On Tue, Mar 9, 2010 at 3:34 AM, Costin Raiciu <c.raiciu@cs.ucl.ac.uk> wrote:

> Hi,
>
> I've skimmed your paper hoping to see big improvements in loading  times
>
> However, the reductions in download times you find are below 10% - and this
> is the best case only a subset of traffic is increasing the initial cwnd.
>

I don't know about you, but imagine a simple change that can deliver a 10%
improvement
(in average) over ALL web traffic regardless of the response sizes (some are
much less than
10 segments), access speed,..., etc. That is A LOT to me!

But of course we'll need to carefully study and understand the possible
negative impact too.

> The experiments in 4.2 show that using Maps in the slowDC scenario can
> negatively affect the download time too for some users, by roughly the same
> amount.

Yes there will always be someone, somewhere, who will be negatively impacted
by any
change to TCP. Ultimately t's a benefit vs cost tradeoff. The negative
impact as shown in
Table 8 is limited to only 4% of the traffic in SlowDC, which is expected to
be one of the
worst performing DCs. Is it fair to write off the win from the rest of 96%
of traffic?

> When all traffic uses the initial cwnd of 10 I expect to see
> smaller improvements or even increases in download times for all web
> traffic.
>

Not sure why you expected so. Note that we strived to turn on IW=10 on the
whole DC scale
in order to measure the worse impact (when a user gets upto IW=10 bursts
from all Google
servers).

> Thus, the 10% average improvement does not seem very compelling to me.

Again the 10% is only the AVERAGE, which in the case of web search includes
a long
backend process time. The micro-level RTT saving is much larger as shown in
the table in
section 5 of the I-D.

Also don't forget to pay attention to the rest of the data in the paper
(besides the gross
average of 10% improvement). When we sliced and diced the data, many are
showing > 20%
latency improvments (Figure 5, 6, Table 6...)

> Have you tested upload speeds? As DSL uploads are 128-256Kbps, I expect
> using an initial cwnd of 10 packets will result in increased loading times
> for web uploads, for instance, in the best case. As DSL lines have buffers
> roughly of that length, causing burst of 10 packets will negatively affect
> all other ongoing connections.
>

Not sure where you get the "10 pkts" data from. My home cable modem (yes
it's faster than
DSL) seems to have many seconds of uplink buffer space). But large buffer
creates a whole
set of different problems and is being address by LEDBAT (?), 10 pkt bursts
seem to be the
least of the problems.

> So it seems to me this may be a good idea to standardize for servers, and
> not for regular hosts. And even for servers, it is hard to understand the
> effects when everybody uses this large init_cwnd.
>

Agreed about the last point. Will need help from folks on this list to
charter a plan forward.

Thanks,

Jerry

>
> Cheers,
> Costin
>
> On 9 Mar 2010, at 00:35, Jerry Chu wrote:
>
> > The link to the paper below has been fixed. Sorry for the delay.
> >
> > Jerry
> >
> > On Tue, Mar 2, 2010 at 2:50 PM, Jerry Chu <hkchu@google.com> wrote:
> > Our first draft proposal to raise the initial congestion window was
> submitted
> > a couple of days ago and is available at
> >
> > http://www.ietf.org/id/draft-hkchu-tcpm-initcwnd-00.txt
> >
> > A paper with the title "An Argument for Increasing TCP’s Initial
> Congestion
> > Window" detailing our large scale experiments will soon be available at
> >
> > http://code.google.com/speed/articles/tcp_initcwnd_paper.pdf
> > (The link is not there yet due to a last minute snag. Hopefully it
> > will be fixed asap.)
> >
> > Comments are welcome.
> >
> > Jerry
> >
> >
> -----------------------------------------------------------------------------------------------------------
> > From: Internet-Drafts@ietf.org
> > To: i-d-announce@ietf.org
> > Reply-to: Internet-Drafts@ietf.org
> > Subject: I-D Action:draft-hkchu-tcpm-initcwnd-00.txt
> > X-RSN: 1/0/935/28943/32298
> > X-HREF: http://www.ietf.org/ibin/c5i?mid=6&rid=49&k1=935&k2=32298
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >
> > Title : Increasing TCP's Initial Window
> > Author(s) : J. Chu, et al.
> > Filename : draft-hkchu-tcpm-initcwnd-00.txt
> > Pages : 16
> > Date : 2010-02-28
> >
> > 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. Finally, it
> > outlines a list of concerns to be addressed in future tests.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-hkchu-tcpm-initcwnd-00.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm
>
>