[Iccrg] "Slow Start" design team

[Dirceu Cavendish]

I believe that a mailing list could facilitate the "narrowness" of the work to be done about a given topic. Having all the work open to a wider audience the people committed to doing the work might dilute the efforts, pulling threads in many directions. Of course everyone in ICCRG may join the list, so the DT structure could degenerate into a full ICCRG group participation. But the idea of a DT is to allow QUICK progress towards a narrow goal.
Having a wider discussion about potentially every step of the work does not sound a good strategy to me.

My proposal then would be to discuss the SCOPE of the SS DT within ICCRG mailing list, and then move to a SSDT mailing list for the bulk of the work...Is there a good compromise between people on both sides of the aisle?

I also wish to clarify that I would be "facilitating" the DT, not leading it :-)
Dirceu

----- Original Message ----
From: John Leslie <john at jlc.net>
To: Michael Welzl <michael.welzl at uibk.ac.at>
Cc: iccrg at cs.ucl.ac.uk
Sent: Tuesday, March 25, 2008 8:05:54 AM
Subject: Re: [Iccrg] "Slow Start" design team

Michael Welzl <michael.welzl at uibk.ac.at> wrote:
> 
> A design team should have a very narrow focus, its own
> mailing list, and be led by someone who is willing and
> able to push the whole thing along.

   Agreed.

> 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.
> 
> To join the list, send an email to:
> iccrg-slowstart-ctl at ndrc.kyutech.ac.jp
> with "subscribe YOUR NAME" as the body of the message.

   I'm not sure a Design Team should be quite that open,
though I'd certainly welcome frequent interaction with the
main iccrg list.

   In any case, I'm holding off on joining that list...

> The first question that should be discussed in this
> list (not here - let's try and move this discussion there
> already) is what exactly the team should focus on:
> 
> * enhancements to the end of slow start (like Dirceu
>   presented at our meeting)
> 
> * different slow start enhancements (like the paper from
>   Injong's group at PFLDNet)
> 
> * something else?

   I strongly recommend nailing down the problem that
Slow-Start is supposed to solve. Without firm agreement
on that, I'm afraid we'll get a random-walk problem.

> * is this only about TCP, or also for other protocols?

   That might be the wrong question. We should start with
a description of what we're trying to fix; then work on
whether fixing it within TCP is even the right place to
start.

--
John Leslie <john at jlc.net>

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






      ____________________________________________________________________________________
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/20080325/4b2df846/attachment.html