<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"><div style="font-family: times new roman,new york,times,serif; font-size: 10pt;">Lachlan,<br><br>I will look at your reference. But taking the risk of a quick reply before that...<br><br>One problem I see is how we can differentiate between RTOs for which the path does not change from the ones that are caused by path change...<br><br>My problem with Quick Start is its required support from routers, before anything else.<br><br>Any solution will have to strike a balance between being too aggressive in certain network scenarios and not being aggressive enough in others. Unless the solution is adaptive...<br><br>But definitely, multiple SS issue should be listed as a separate one, although it may be triggered by overshooting of the buffer at large BDP, already listed...<br><br>Thanks for pointing that
out.<br>Dirceu<br><br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">----- Original Message ----<br>From: Lachlan Andrew <lachlan.andrew@gmail.com><br>To: Dirceu Cavendish <dirceu_cavendish@yahoo.com><br>Cc: "iccrg@cs.ucl.ac.uk" <iccrg@cs.ucl.ac.uk><br>Sent: Friday, March 28, 2008 10:51:09 AM<br>Subject: Re: [Iccrg] SSDT Scope - summary<br><br>
Greetings Dirceu,<br><br>One "low-hanging fruit" would be to fix a slow start which occurs<br>after timeout or an idle period, rather than at the start of a<br>connection. In these cases, the sender has a good guess at the right<br>BDP. In Chicago, Sally gave a presentation suggestion quadrupling<br>(instead of doubling) up to the guessed BDP. That helps problem 1,<br>but exacerbates problem 2.<br><br>If we have an estimate of the BDP, then *both* problems can be solved<br>by increasing the rate linearly (at a suitable rate) rather than<br>exponentially. Take a look at<br><<a href="http://netlab.caltech.edu/lachlan/abstract/AIslowstart.pdf" target="_blank">http://netlab.caltech.edu/lachlan/abstract/AIslowstart.pdf</a>> if you're<br>interested.<br><br>Personally, I'm not a fan of QuickStart/JumpStart, because it doesn't<br>give other flows enough time to back off. However, using QuickStart<br>signalling to specify the
final BDP would allow this linear increase<br>over a suitable number of RTTs for slow start at the start of a<br>connection too.<br><br>$0.02,<br>Lachlan<br><br>On 28/03/2008, Dirceu Cavendish <<a ymailto="mailto:dirceu_cavendish@yahoo.com" href="mailto:dirceu_cavendish@yahoo.com">dirceu_cavendish@yahoo.com</a>> wrote:<br>><br>> I went through this week's messages on SS topics, and here is a summary of<br>> them:<br>><br>> - Transaction latencies taking too long to complete, in a large bandwidth<br>> delay product networks.<br>> - Buffer overshoot, causing multiple segment losses/retransmits, potentially<br>> causing RTOs<br>><br>> The first item can be seen as SS being too conservative/slow, whereas the<br>> second one may be cast as SS being too aggressive in doubling cwnd when<br>> current cwnd is large (high BDP networks). So, my proposal would be to scope<br>> the SSDT as to CHARACTERIZE these two issues
first. Depending on how fast we<br>> go with this work, we can then address/analyze solutions, such as Quick<br>> Start, limited slow start, and others...But I think a good characterization<br>> will bring already the features we would like to see in a solution, without<br>> having to lock ourselves up to any one.<br>><br>> Dirceu<br>><br>><br>><br>> ________________________________<br>> Looking for last minute shopping deals? Find them fast with Yahoo! Search.<br>> _______________________________________________<br>> Iccrg mailing list<br>> <a ymailto="mailto:Iccrg@cs.ucl.ac.uk" href="mailto:Iccrg@cs.ucl.ac.uk">Iccrg@cs.ucl.ac.uk</a><br>> <a href="http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg" target="_blank">http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg</a><br>><br>><br><br><br>-- <br>Lachlan Andrew Dept of Computer Science, Caltech<br>1200 E California Blvd, Mail
Code 256-80, Pasadena CA 91125, USA<br>Ph: +1 (626) 395-8820 Fax: +1 (626) 568-3603<br><a href="http://netlab.caltech.edu/lachlan" target="_blank">http://netlab.caltech.edu/lachlan</a><br></div><br></div></div><br>
<hr size=1>Looking for last minute shopping deals? <a href="http://us.rd.yahoo.com/evt=51734/*http://tools.search.yahoo.com/newsearch/category.php?category=shopping">
Find them fast with Yahoo! Search.</a></body></html>