<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>Back to Lachlan initial email, it seems that the low hanging fruit of :application limited" re-start</P>
<P>is a good way to start experimenting with faster than SS schemes.</P>
<P> </P>
<P>HOWEVER, the characterization of the other cases, as discussed in this thread, is also a valuable contribution.</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 Welzl <michael.welzl@uibk.ac.at><BR>To: Lachlan Andrew <lachlan.andrew@gmail.com><BR>Cc: Dirceu Cavendish <dirceu_cavendish@yahoo.com>; "iccrg@cs.ucl.ac.uk" <iccrg@cs.ucl.ac.uk><BR>Sent: Monday, March 31, 2008 12:19:37 AM<BR>Subject: Re: [Iccrg] SSDT Scope - summary<BR><BR>> 1. I agree that resuming after "application constrained" is a more<BR>> clear-cut case for more rapid increase. If we can improve that case,<BR><BR>Me too.<BR><BR><BR>> 2. It isn't clear to me that the possibility of path changes is a<BR>> sufficient reason not to use better slow-start after timeout.<BR><BR>That was just an example - my point is that, generally, we<BR>should assume to know nothing after an RTO<BR><BR><BR>> 2a) We still start from a low rate and build up, stopping if we get a loss<BR><BR>as with
original slow start :)<BR><BR><BR>> 2b) Most route changes will be between "similar" links -- like<BR>> rerouting within a backbone. We'd only have problems if, for example,<BR>> we were forced off a GbE link onto an ADSL backup link<BR><BR>too much guesswork IMO<BR><BR><BR>> 2c) Even if we do overshoot significantly, we'll get a stack of losses<BR>> and time out again, but this time with a reduced ssthresh.<BR><BR>as with original slow start<BR><BR><BR>conclusion: while I'm generally in favor of making slow start<BR>a bit faster in its initial phase, your points above don't<BR>convince me that this would better be done when an RTO occurs<BR>during a connection.<BR><BR><BR>> There may be a smarter way to make use of the fact that we have *some*<BR>> information about probability distribution of the BDP.<BR><BR>yup - if we do, as it might be reasonable to assume in<BR>the app-limited
case<BR><BR>cheers<BR>michael<BR><BR><BR></DIV><BR></DIV></div><br>
<hr size=1><a href="http://us.rd.yahoo.com/evt=47519/*http://tc.deals.yahoo.com/tc/blockbuster/text1.com
">No Cost - Get a month of Blockbuster Total Access</a> now. Sweet deal for Yahoo! users and friends.</body></html>