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

From: Jerry Chu <[email-masked]>
Date: Tue, 2 Mar 2010 14:50:51 -0800

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: [email-masked]
To: [email-masked]
Reply-to: [email-masked]
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/

---

From: Jerry Chu <[email-masked]>
Date: Mon, 8 Mar 2010 16:35:03 -0800

The link to the paper below has been fixed. Sorry for the delay.

Jerry

---

From: Costin Raiciu <[email-masked]>
Date: Tue, 9 Mar 2010 11:34:43 +0000

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

Thus, the 10% average improvement does not seem very compelling to me. 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.

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.

Cheers,
Costin

On 9 Mar 2010, at 00:35, Jerry Chu wrote:

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Jerry Chu <[email-masked]>
Date: Tue, 9 Mar 2010 11:25:29 -0800

On Tue, Mar 9, 2010 at 3:34 AM, Costin Raiciu <[email-masked]> wrote:

> 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

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

---

From: rick jones <[email-masked]>
Date: Tue, 09 Mar 2010 19:35:47 -0800

On Mar 9, 2010, at 11:25 AM, Jerry Chu wrote:
> 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

Indeed, 10% average improvement is impressive.

Is there a way to tease-out what the "typical" cwnd becomes in both  
the base and exp cases?  Say from those services with larger  
responses? Does it become 8*MSS?  12*MSS etc?  That would help show  
how "close to the edge" 10 segments might be yes?

WRT the retransmissions (table 7 in the paper), is it safe to ass-u-me  
that the increase in retransmissions means a corresponding increase in  
"Internet" bandwidth consumed to deliver the given quantity of data?

rick jones
there is no rest for the wicked, yet the virtuous have no pillows
wisdom teeth are impacted, people and things are affected by the  
effects of events :)

---

From: Jerry Chu <[email-masked]>
Date: Tue, 9 Mar 2010 22:07:17 -0800

On Tue, Mar 9, 2010 at 7:35 PM, rick jones <[email-masked]> wrote:
>> (in average) over ALL web traffic regardless of the response sizes (some
>> are much less than
> Is there a way to tease-out what the "typical" cwnd becomes in both the base
> and exp cases?  Say from those services with larger responses? Does it
> become 8*MSS?  12*MSS etc?  That would help show how "close to the edge" 10
> segments might be yes?

Yes it's certainly doable but one problem with most of the services is
that there are
fewer larger responses, interleaved with many smaller responses, and the vast
majority of HTTP connections don't persist long enough to allow cwnd/ssthresh to
converge in a more meaningful way.

In order to perform a more detailed analysis on some network properties, we are
thinking about instrumenting a bulk data service like Youtube to avoid the above
mentioned problem, as described in section 11.2 of the I-D. The idea
is to monitor
some key TCP parameters at various stage of a connection (and Linux kernel
already conveniently provide "TCP_INFO" socket option). But before we proceed
we like to first hear suggestions from the lists. This is because any
large scale
experiment can be very time/resource consuming. In this case we'll likely have
to set up a different logging system for Youtube, may even have to
build and deploy
a different kernel with the right instrumentation (TCP_INFO may not provide all
the info we'll need) to many thousand machines..., etc.

>
> WRT the retransmissions (table 7 in the paper), is it safe to ass-u-me that
> the increase in retransmissions means a corresponding increase in "Internet"
> bandwidth consumed to deliver the given quantity of data?

I don't see why not. (Am I missing something?)

Thanks,

Jerry

> wisdom teeth are impacted, people and things are affected by the effects of
> events :)
>

---

From: rick jones <[email-masked]>
Date: Wed, 10 Mar 2010 08:02:08 -0800

On Mar 9, 2010, at 10:07 PM, Jerry Chu wrote:

>> the base
> that there are fewer larger responses, interleaved with many smaller  
> responses, and the vast
> is to monitor some key TCP parameters at various stage of a  
> connection (and Linux kernel
> large scale experiment can be very time/resource consuming. In this  
> case we'll likely have
> build and deploy a different kernel with the right instrumentation  
> (TCP_INFO may not provide all

I probably would simply start with logging the cwnd, ssthresh,  
retransmission count and bytes transferred at the end of a  
connection.  Without having any firm basis to support it, I suspect  
that cwnd at the end of the connection is "good enough" and one  
doesn't need max cwnd.

> I don't see why not. (Am I missing something?)

Probably not - I was simply wondering if I might have been - it does  
call for chaining an assumption or two about the distribution of the  
size of the retransmitted segments versus the whole along with the  
acceptance that 99 times out of 10 the losses are in the last mile.

rick jones
Wisdom teeth are impacted, people are affected by the effects of events