[Iccrg] SSDT Scope - summary

Lachlan Andrew lachlan.andrew at gmail.com
Fri Mar 28 17:51:09 GMT 2008


Greetings Dirceu,

One "low-hanging fruit" would be to fix a slow start which occurs
after timeout or an idle period, rather than at the start of a
connection.  In these cases, the sender has a good guess at the right
BDP.  In Chicago, Sally gave a presentation suggestion quadrupling
(instead of doubling) up to the guessed BDP.  That helps problem 1,
but exacerbates problem 2.

If we have an estimate of the BDP, then *both* problems can be solved
by increasing the rate linearly (at a suitable rate) rather than
exponentially.  Take a look at
<http://netlab.caltech.edu/lachlan/abstract/AIslowstart.pdf> if you're
interested.

Personally, I'm not a fan of QuickStart/JumpStart, because it doesn't
give other flows enough time to back off.  However, using QuickStart
signalling to specify the final BDP would allow this linear increase
over a suitable number of RTTs for slow start at the start of a
connection too.

$0.02,
Lachlan

On 28/03/2008, Dirceu Cavendish <dirceu_cavendish at yahoo.com> wrote:
>
> I went through this week's messages on SS topics, and here is a summary of
> them:
>
> - Transaction latencies taking too long to complete, in a large bandwidth
> delay product networks.
> - Buffer overshoot, causing multiple segment losses/retransmits, potentially
> causing RTOs
>
> The first item can be seen as SS being too conservative/slow, whereas the
> second one may be cast as SS being too aggressive in doubling cwnd when
> current cwnd is large (high BDP networks). So, my proposal would be to scope
> the SSDT as to CHARACTERIZE these two issues first. Depending on how fast we
> go with this work, we can then address/analyze solutions, such as Quick
> Start, limited slow start, and others...But I think a good characterization
> will bring already the features we would like to see in a solution, without
> having to lock ourselves up to any one.
>
> Dirceu
>
>
>
>  ________________________________
> Looking for last minute shopping deals? Find them fast with Yahoo! Search.
> _______________________________________________
>  Iccrg mailing list
>  Iccrg at cs.ucl.ac.uk
>  http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>


-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: +1 (626) 395-8820    Fax: +1 (626) 568-3603
http://netlab.caltech.edu/lachlan



More information about the Iccrg mailing list