[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