<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:10pt"><P>Michael,</P>
<P> </P>
<P>Good charts. Question: how did you pick the specific 82Mbps and 5.1Mbps request values? Why didnt you request 9Mbps on a 10Mbps link?</P>
<P> </P>
<P>Dirceu</P>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: times new roman, new york, times, serif"><BR><BR>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">----- Original Message ----<BR>From: Michael Scharf <michael.scharf@ikr.uni-stuttgart.de><BR>To: iccrg-slowstart@infonet.cse.kyutech.ac.jp<BR>Cc: iccrg IRTF list <iccrg@cs.ucl.ac.uk><BR>Sent: Tuesday, April 15, 2008 12:33:04 PM<BR>Subject: [iccrg-slowstart 00007] Re: [Iccrg] SSDT contributions<BR><BR>Dirceu,<BR><BR>in simple usage scenarios (e. g., HTTP/1.0-like communication) the<BR>impact of Slow-Start is rather obvious, as well as the potential<BR>speedup that faster algorithms could achieve.<BR><BR>The attached slides show some Linux measurement results that compare<BR>the Slow-Start with Quick-Start (best case). There can be a<BR>performance improvement of one second or more, which is typically<BR>"user perceivable". The difference would be even larger if the TCP<BR>stacks used delayed ACKs (Linux disables them sometimes). Of course,<BR>the larger the RTT,
the more significant is the effect.<BR><BR>I also have data for more realistic HTTP request patterns, but in this<BR>case the Slow-Start impact is more difficult to quantify and depends a<BR>lot on the application communication pattern.<BR><BR>Michael<BR><BR>On Fri, 11 Apr 2008 at 10:45:20, Dirceu Cavendish wrote:<BR>> Michael,<BR>> <BR>> I think the "user perceivable" impact of faster SS algorithms should be documented within ICCRG. Do you have data backing that up (for any application of your choice)?<BR>> <BR>> I am attaching few slides on experimental results in reducing segment losses during SS, for discussion. As presented in Manchester, we reduce losses by both reducing the speed of cwnd increase (in a fractional rather than by 1 way), as well as NOT transmitting the entire cwnd on a back-to-back fashion - introducing "micro-pauses" during transmissions...<BR>> <BR>> Dirceu<BR></DIV><BR></DIV></div><br>
between 0000-00-00 and 9999-99-99
</body></html>