[Iccrg] SSDT Scope - summary

[Dirceu Cavendish]

Lachlan,

I will look at your reference. But taking the risk of a quick reply before that...

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...

My problem with Quick Start is its required support from routers, before anything else.

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...

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...

Thanks for pointing that out.
Dirceu


----- Original Message ----
From: Lachlan Andrew <lachlan.andrew at gmail.com>
To: Dirceu Cavendish <dirceu_cavendish at yahoo.com>
Cc: "iccrg at cs.ucl.ac.uk" <iccrg at cs.ucl.ac.uk>
Sent: Friday, March 28, 2008 10:51:09 AM
Subject: Re: [Iccrg] SSDT Scope - summary

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






      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080328/fdf50548/attachment-0001.html