[Iccrg] SSDT Scope

Wed Mar 26 20:31:18 GMT 2008

If i am a web app and i have say some small data to transfer, today in slow start it would take multiple round trips to transfer this data, now say i negotiated a rate with quick start or started with higher cwnd i could complete the transaction faster and be done. I have seen customers complain about this esp when they are on high latency low bandwidth links.
________________________________
From: Dirceu Cavendish [dirceu_cavendish at yahoo.com]
Sent: Wednesday, March 26, 2008 1:15 PM
To: Murari Sridharan; iccrg at cs.ucl.ac.uk
Subject: Re: [Iccrg] SSDT Scope

Inline comments:

----- Original Message ----
From: Murari Sridharan <muraris at microsoft.com>
To: Dirceu Cavendish <dirceu_cavendish at yahoo.com>; "iccrg at cs.ucl.ac.uk" <iccrg at cs.ucl.ac.uk>
Sent: Wednesday, March 26, 2008 12:21:18 PM
Subject: RE: [Iccrg] SSDT Scope

I have heard two sets of complaints about slow start; one its too slow, in the sense for connections that usually never get out of slow start and are latency sensitive need something faster. Proposals; second is nto really a customer complaint per-se but not good behavior in general, which is that slow start doubles rate before it hits a loss and this overshooting of buffer should be avoided if we can detect it.

Now the first problem is already addressed to some extent by proposals like Limited Slowstart, QuickStart etc . is SSDT’s goal to improve those solutions?

<dc> I confess I am a bit confused with your last statement about limited slow start and quickstart as solutions to connections that usually never get out of slow start. How does limited slow start help there? I would understand limited slow start helping the second issue as described above...

I also would rather keep the discussion about what are the current SS issues worthy to work on, rather than to jump into a discussion on possible solutions of issues that potentially are not found worth pursuing them. Also, it may be that we agree that a tangible and hence worth pursuing contribution would be to come-up with a document describing the relevant limitations of SS, as the ICCRG sees it.

Dirceu
</dc>

From: iccrg-bounces at cs.ucl.ac.uk [mailto:iccrg-bounces at cs.ucl.ac.uk] On Behalf Of Dirceu Cavendish
Sent: Wednesday, March 26, 2008 10:24 AM
To: iccrg at cs.ucl.ac.uk
Subject: [Iccrg] SSDT Scope

On Michael's advise, I am re-sending this message to the ICCRG mailing list.

Hello people interested in Slow Start.
The first discussion is about the scope of the SSDT group. A good starting point is to list what people have experienced as incovenient behavior of slow start. Once we agree on what to address, we can scope the objectives/goals of the SSDT group.

Our "pain points" are:

- multiple segment losses in high bandwidth delay product networks, when SS opens the cwnd to a large value right before transitioning from SS to CA. This typically causes multiple RTOs...
- Unfairness with different session RTTs.

Feel free to add yours.
Dirceu

----- Original Message ----
From: Lachlan Andrew <lachlan.andrew at gmail.com>
To: Michael Welzl <michael.welzl at uibk.ac.at>
Cc: iccrg at cs.ucl.ac.uk
Sent: Tuesday, March 25, 2008 8:04:48 AM
Subject: Re: [Iccrg] "Slow Start" design team

Greetings Michael and Lars,

An advantage of separate mailing lists is that it allows people set up
filters for the mail clients.  That could also be done by asking
people to put a keyword in their email subjects (like slowstartDT).

FWIW, I'm unlikely to subscribe to the DT mailing lists, but wouldn't
mind extra traffic on  iccrg at ...

Cheers,
Lachlan

On 25/03/2008, Michael Welzl <michael.welzl at uibk.ac.at<mailto:michael.welzl at uibk.ac.at>> wrote:
> On Tue, 2008-03-25 at 16:05 +0200, Lars Eggert wrote:
>  > On 2008-3-25, at 15:54, ext Michael Welzl wrote:
>  > > The first concrete proposal on the table is (somewhat
>  > > unsurprisingly  :)  ) a design team on Slow Start,
>  > > led by Dirceu himself (which I, not he, suggested).
>  > > I think it's a nice start and definitely worth trying.
>  >
>  > Sounds good.
>  >
>  > > To join the list, send an email to:
>  > > iccrg-slowstart-ctl at ndrc.kyutech.ac.jp<mailto:iccrg-slowstart-ctl at ndrc.kyutech.ac.jp>
>  > > with "subscribe YOUR NAME" as the body of the message.
>  >
>  > But why does the DT need its own list? It's not like the ICCRG list is
>  > flooded with traffic, and having the discussions in the open seems
>  > useful.
>
>
> ah, that was just an idea ... after all there should be
>  multiple design teams with multiple lists one day
>
>  we could have it all in the open if people want that,
>  but it just seems to make things a little more organized
>  to me ... dunno, doesn't really matter i suppose
>
>  cheers
>
> michael
>
>
>
>
>  _______________________________________________
>  Iccrg mailing list
>  Iccrg at cs.ucl.ac.uk<mailto: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

_______________________________________________
Iccrg mailing list
Iccrg at cs.ucl.ac.uk<mailto:Iccrg at cs.ucl.ac.uk>
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

________________________________
Never miss a thing. Make Yahoo your homepage.<http://us.rd.yahoo.com/evt=51438/*http:/www.yahoo.com/r/hs>

________________________________
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.<http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080326/404fa079/attachment.html