[Iccrg] SSDT Scope
Dirceu Cavendish
dirceu_cavendish at yahoo.com
Thu Mar 27 17:43:29 GMT 2008
Michael,
I personally prefer some "self-pacing" (ack driven) solution, rather than relying on kernet timers. But I guess solutions can be discussed in the SSDT group, once we agree on the topics to work on.
In case we work on "speeding up" SS topic, your help on evaluating Quick Start versus some other solution will be very helpful. I am glad you have already volunteered to take part on SSDT ;-)...
Rgds,
Dirceu
----- Original Message ----
From: Michael Scharf <michael.scharf at ikr.uni-stuttgart.de>
To: Murari Sridharan <muraris at microsoft.com>
Cc: Dirceu Cavendish <dirceu_cavendish at yahoo.com>; "iccrg at cs.ucl.ac.uk" <iccrg at cs.ucl.ac.uk>
Sent: Thursday, March 27, 2008 3:04:32 AM
Subject: Re: [Iccrg] SSDT Scope
Concerning problem #1: I wonder whether it could be time to think of
alternatives to RFC 3390 (in mid-term future).
For instance, would it cause sever problems in today's Internet if the
initial window was further increased by one or two segments?
Or, could some simple form of rate-pacing help those guys that
complain about the speed of Slow-Start when the RTT/BDP is large? For
instance, after the 3-way handshake, one could allow a sender to
increase the cwnd beyond the initial value after 100ms or 200ms if no
new ACK has been received until then. This would help short flows over
a path with a rather large RTT. Maybe such an approach could be
combined with a solution that reduces the aggressiveness of Slow-Start
when cwnd is larger.
(Of course, Quick-Start would be my favorite solution.)
Michael
On Wed, 26 Mar 2008 at 14:54:45, Murari Sridharan wrote:
> I see the confusion in my original mail. I misspoke. I meant to give the two problems that I am aware of of and state some IETF effort in solving each. Quickstart as an example of something that would address problem 1 and some requests that I have seen where customers want to start with a high value of cwnd, and limited slow start as something that would address #2. For connections that never leave slow start, limited slow start is going to slow things further.
>
> Now as part of SSDT motivation, we should agree on what problems we are solving and given there is some prior effort we should also say why these solutions are not sufficient or alternatively may have deployment blockers.
>
> Thanks
> Murari
>
> From: Dirceu Cavendish [mailto:dirceu_cavendish at yahoo.com]
> Sent: Wednesday, March 26, 2008 1:53 PM
> To: Murari Sridharan; iccrg at cs.ucl.ac.uk
> Subject: Re: [Iccrg] SSDT Scope
>
>
> I am aware how quickStart helps with Web Service transactions. My question was about how limited slow start helps with that, which was I understood from your previous message...
>
>
>
> Dirceu
>
> ----- 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 1:31:18 PM
> Subject: RE: [Iccrg] SSDT Scope
> 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>
>
>
> ________________________________
> Looking for last minute shopping deals? Find them fast with Yahoo! Search.<http://us.rd.yahoo.com/evt=51734/*http:/tools.search.yahoo.com/newsearch/category.php?category=shopping>
> _______________________________________________
> Iccrg mailing list
> Iccrg at cs.ucl.ac.uk
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
--
Dipl.-Ing. Michael Scharf
Institute of Communication Networks and Computer Engineering (IKR)
Universität Stuttgart, Pfaffenwaldring 47, 70569 Stuttgart, Germany
Phone: +49 711 685-69006 Email: michael.scharf at ikr.uni-stuttgart.de
Fax: +49 711 685-67983 Web: www.ikr.uni-stuttgart.de/en/~scharf
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080327/1034a8bb/attachment-0001.html
More information about the Iccrg
mailing list