On Tue, Mar 9, 2010 at 3:34 AM, Costin Raiciu <span dir="ltr"><<a href="mailto:c.raiciu@cs.ucl.ac.uk">c.raiciu@cs.ucl.ac.uk</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<br>
I've skimmed your paper hoping to see big improvements in loading times<br>
<br>
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.<br></blockquote><div> </div><div>I don't know about you, but imagine a simple change that can deliver a 10% improvement<br>
(in average) over ALL web traffic regardless of the response sizes (some are much less than<br>10 segments), access speed,..., etc. That is A LOT to me!<br><br>But of course we'll need to carefully study and understand the possible negative impact too.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.</blockquote><div><br>Yes there will always be someone, somewhere, who will be negatively impacted by any<br>
change to TCP. Ultimately t's a benefit vs cost tradeoff. The negative impact as shown in<br>Table 8 is limited to only 4% of the traffic in SlowDC, which is expected to be one of the<br>worst performing DCs. Is it fair to write off the win from the rest of 96% of traffic?<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">When all traffic uses the initial cwnd of 10 I expect to see<br>
smaller improvements or even increases in download times for all web traffic.<br></blockquote><div><br>Not sure why you expected so. Note that we strived to turn on IW=10 on the whole DC scale<br>in order to measure the worse impact (when a user gets upto IW=10 bursts from all Google<br>
servers).<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Thus, the 10% average improvement does not seem very compelling to me.</blockquote><div><br>Again the 10% is only the AVERAGE, which in the case of web search includes a long<br>backend process time. The micro-level RTT saving is much larger as shown in the table in<br>
section 5 of the I-D.<br><br>Also don't forget to pay attention to the rest of the data in the paper (besides the gross<br>average of 10% improvement). When we sliced and diced the data, many are showing > 20%<br>latency improvments (Figure 5, 6, Table 6...)<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.<br>
</blockquote><div><br>Not sure where you get the "10 pkts" data from. My home cable modem (yes it's faster than<br>DSL) seems to have many seconds of uplink buffer space). But large buffer creates a whole<br>
set of different problems and is being address by LEDBAT (?), 10 pkt bursts seem to be the<br>least of the problems.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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.<br></blockquote><div><br>
Agreed about the last point. Will need help from folks on this list to charter a plan forward.<br><br>Thanks,<br><br>Jerry<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Cheers,<br>
Costin<br>
<div><div></div><div class="h5"><br>
On 9 Mar 2010, at 00:35, Jerry Chu wrote:<br>
<br>
> The link to the paper below has been fixed. Sorry for the delay.<br>
><br>
> Jerry<br>
><br>
> On Tue, Mar 2, 2010 at 2:50 PM, Jerry Chu <<a href="mailto:hkchu@google.com">hkchu@google.com</a>> wrote:<br>
> Our first draft proposal to raise the initial congestion window was submitted<br>
> a couple of days ago and is available at<br>
><br>
> <a href="http://www.ietf.org/id/draft-hkchu-tcpm-initcwnd-00.txt" target="_blank">http://www.ietf.org/id/draft-hkchu-tcpm-initcwnd-00.txt</a><br>
><br>
> A paper with the title "An Argument for Increasing TCP’s Initial Congestion<br>
> Window" detailing our large scale experiments will soon be available at<br>
><br>
> <a href="http://code.google.com/speed/articles/tcp_initcwnd_paper.pdf" target="_blank">http://code.google.com/speed/articles/tcp_initcwnd_paper.pdf</a><br>
> (The link is not there yet due to a last minute snag. Hopefully it<br>
> will be fixed asap.)<br>
><br>
> Comments are welcome.<br>
><br>
> Jerry<br>
><br>
> -----------------------------------------------------------------------------------------------------------<br>
> From: <a href="mailto:Internet-Drafts@ietf.org">Internet-Drafts@ietf.org</a><br>
> To: <a href="mailto:i-d-announce@ietf.org">i-d-announce@ietf.org</a><br>
> Reply-to: <a href="mailto:Internet-Drafts@ietf.org">Internet-Drafts@ietf.org</a><br>
> Subject: I-D Action:draft-hkchu-tcpm-initcwnd-00.txt<br>
> X-RSN: 1/0/935/28943/32298<br>
> X-HREF: <a href="http://www.ietf.org/ibin/c5i?mid=6&rid=49&k1=935&k2=32298" target="_blank">http://www.ietf.org/ibin/c5i?mid=6&rid=49&k1=935&k2=32298</a><br>
><br>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.<br>
><br>
> Title : Increasing TCP's Initial Window<br>
> Author(s) : J. Chu, et al.<br>
> Filename : draft-hkchu-tcpm-initcwnd-00.txt<br>
> Pages : 16<br>
> Date : 2010-02-28<br>
><br>
> This document proposes an increase in the permitted TCP initial<br>
> window (IW) from between 2 and 4 segments, as specified in RFC 3390,<br>
> to 10 segments. It discusses the motivation behind the increase, the<br>
> advantages and disadvantages of the higher initial window, and<br>
> presents results from several large scale experiments showing that<br>
> the higher initial window improves the overall performance of many<br>
> web services without risking congestion collapse. Finally, it<br>
> outlines a list of concerns to be addressed in future tests.<br>
><br>
> A URL for this Internet-Draft is:<br>
> <a href="http://www.ietf.org/internet-drafts/draft-hkchu-tcpm-initcwnd-00.txt" target="_blank">http://www.ietf.org/internet-drafts/draft-hkchu-tcpm-initcwnd-00.txt</a><br>
><br>
> Internet-Drafts are also available by anonymous FTP at:<br>
> <a href="ftp://ftp.ietf.org/internet-drafts/" target="_blank">ftp://ftp.ietf.org/internet-drafts/</a><br>
><br>
</div></div>> _______________________________________________<br>
> tcpm mailing list<br>
> <a href="mailto:tcpm@ietf.org">tcpm@ietf.org</a><br>
> <a href="https://www.ietf.org/mailman/listinfo/tcpm" target="_blank">https://www.ietf.org/mailman/listinfo/tcpm</a><br>
<br>
</blockquote></div><br>