[Iccrg] SSDT Scope

[[e-mail] [mailto:[e-mail]] On Behalf Of Dirceu Cavendish]

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 <[e-mail]>
To: Michael Welzl <[e-mail]>
Cc: [e-mail]
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@...

Cheers,
Lachlan

On 25/03/2008, Michael Welzl <[e-mail]> 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:
>  > > [e-mail]
>  > > 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
>  [e-mail]
>  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: [phone]    Fax: [phone]
http://netlab.caltech.edu/lachlan

_______________________________________________
Iccrg mailing list
[e-mail]
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
 
 



Never miss a thing. Make Yahoo your homepage.
 
 



Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
 
 



Looking for last minute shopping deals? Find them fast with Yahoo! Search.


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080326/489bb2a2/attachment.html
>From [e-mail]  Thu Mar 27 13:56:45 2008
From: [e-mail] (Eddy, Wesley M. (GRC-RCN0)[VZ])
Date: Thu Mar 27 13:59:40 2008
Subject: [Iccrg] updated RG CTCP review
Message-ID: <[e-mail]>

Based on the responses to the first draft, and the discussion
we had in Philadelphia, I've prepared an update to the RG's
Compound TCP review (attached).  Please look this over in
the next two weeks, and we will forward it to TCPM if no major
changes are noted by then.

I've added links to some of the implementation and
experimental results, and to mailing list discussions.
If there are other links that should be added to provide
even more backup, please note it to us.

Thanks for your help (and patience!) in completing this first
review for TCPM.
-------------- next part --------------
In July 2007, the ICCRG began reviewing the Compound TCP congestion control
technique described in draft-sridharan-tcpm-ctcp-00 in terms of its safety for
widespread experimental deployment on the public Internet.  This review was
conducted as an input to the IETF TCPM working group, where the draft was being
considered for possible Experimental publication.  The scope of this review
does not include making or endorsing any claims about expected performance
gains from using Compound TCP.

Based on initial RG comments, an update to the original internet-draft was
published.  Based on further RG comments, another update is expected that
contains several clarifications (itemized later within this document).  This
review assumes that those changes are made.

After reviewing the draft and a number of other documents with results from
testing and simulation, three public evaluations were submitted to the ICCRG by
RG participants.  Several follow-on messages and comments were submitted by
these and other RG participants.  Multiple independent implementations have
been done of Compound TCP at this point in time.  Compound TCP has been
experimented with in both simulators, testbeds, and campus/enterprise networks.
On the matter of safety for experimental use, the implementers and experimenters
seem to agree that the algorithm is safe, though in individual implementations,
bugs have been found, unrelated to the algorithm itself. It is possible that
clarifications to the specification will help to avoid this.  The RG seems to
have consensus that (given the expected draft clarifications) the Compound TCP
mechanism is safe for experimental deployment on the public Internet.

References to RG participants' reviews and papers, presentations, and mailing
list messages that contributed to the consensus-forming are provided at the
end of this document.

Its novelty from the current Standards Track congestion control techniques is
that Compound TCP also contains a delay-based component.  Compound TCP's
design only utilizes the delay-based component when loss is low and the
congestion window has already grown large, and in other conditions reversts
to the current Standards Track mechanisms.  This was noted by some reviewers
as one inspiration of confidence.  The simulation results and analysis made
available were also helpful, but were not found to be overwhelmingly convincing
on their own. The implementation experiences, testbed work, and campus
deployments weighed most heavily in the RG's mind as evidence of Compound TCP's
safety.

There was an open discussion item on the use of estimation algorithms for the
queueing delay.  There was also a question lingering about how the algorithm
behaves in wireless environments where latency variations may not be completely
due to congestion, and a security-related question as to the possibility to
disrupt the delay-based component by altering the material used to take delay
samples.  These questions seem to apply to any congestion control algorithm
that utilizes delay as a source of congestion information.

Expected changes from the 01 draft version:

1. Clarify how RTT samples are captured (1323 or some other filter).

2. Clarify definition of baseRTT. (noted by 2 reviewers)

3. Clarify definition of "round" in dwnd update (is it in terms of RTT or cwnd
   worth of packets).

4. What happens to dwnd during slow-start, and when is slow-start
   exited?

5. Clarify dwnd update parameters and specific values or ranges that are safe
   for use (alpha, beta, eta, k) (noted by 3 reviewers)

6. Be precise about clipping dwnd so that it cannot become negative


Public reviews from:
Wesley Eddy (Nov 1, 2007)
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-November/000358.html
Mark Allman (Nov 29, 2007)
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-November/000378.html
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-November/000379.html
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-November/000380.html
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-November/000381.html
Doug Leith (Jan 16, 2008)
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-January/000402.html

Additionally, several thread comments from:
Lachlan Andrew
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-February/000416.html
Michael Welzl
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-February/000411.html
Dino-Martin Lopez-Pacheco
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-February/000415.html
  

Slides showing design and behavior:
  http://research.microsoft.com/users/dthaler/IETF%20-%20Compound%20TCP.pdf
INFOCOM 2006 paper:
  http://research.microsoft.com/users/dthaler/ctcp-infocom06.pdf
Evaluation by Doug Leith, Lachlan Andrew, Tom Quetchenbach, Bob Shorten,
 and Kfir Lavi, based on independent implementation:
  http://www.hep.man.ac.uk/PFLDnet2008/paper/Leith_DJ_Experimental%20Final.pdf
  http://www.welzl.at/iccrg-mar08-slides/iccrg_compound_mar08.ppt.pdf
Evaluation by SLAC (Yee-Ting Li):
  http://www.slac.stanford.edu/pubs/slactns/tn04/slac-tn-06-005.pdf
Behavior on under-buffered links:
  http://www.hep.man.ac.uk/PFLDnet2008/paper/Kun_T%20Final.pdf
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-March/000441.html
>From [e-mail]  Thu Mar 27 17:43:29 2008
From: [e-mail] (Dirceu Cavendish)
Date: Thu Mar 27 17:35:37 2008
Subject: [Iccrg] SSDT Scope
Message-ID: <[e-mail]>

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 <[e-mail]>
To: Murari Sridharan <[e-mail]>
Cc: Dirceu Cavendish <[e-mail]>; "[e-mail]" <[e-mail]>
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:[e-mail]]
> Sent: Wednesday, March 26, 2008 1:53 PM
> To: Murari Sridharan; [e-mail]
> 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 <[e-mail]>
> To: Dirceu Cavendish <[e-mail]>; "[e-mail]" <[e-mail]>
> 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 [[e-mail]]
> Sent: Wednesday, March 26, 2008 1:15 PM
> To: Murari Sridharan; [e-mail]
> Subject: Re: [Iccrg] SSDT Scope
> Inline comments:
> 
> ----- Original Message ----
> From: Murari Sridharan <[e-mail]>
> To: Dirceu Cavendish <[e-mail]>; "[e-mail]" <[e-mail]>
> 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: [e-mail] [mailto:[e-mail]] On Behalf Of Dirceu Cavendish
> Sent: Wednesday, March 26, 2008 10:24 AM
> To: [e-mail]
> 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 <[e-mail]>
> To: Michael Welzl <[e-mail]>
> Cc: [e-mail]
> 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@...
> 
> Cheers,
> Lachlan
> 
> On 25/03/2008, Michael Welzl <[e-mail]<mailto:[e-mail]>> 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:
> >  > > [e-mail]<mailto:[e-mail]>
> >  > > 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
> >  [e-mail]<mailto:[e-mail]>
> >  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: [phone]    Fax: [phone]
> http://netlab.caltech.edu/lachlan
> 
> _______________________________________________
> Iccrg mailing list
> [e-mail]<mailto:[e-mail]>
> 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
> [e-mail]
> 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: [phone] Email: [e-mail]
Fax:  [phone] 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
>From [e-mail]  Thu Mar 27 10:04:32 2008
From: [e-mail] (Michael Scharf)
Date: Fri Mar 28 07:00:44 2008
Subject: [Iccrg] SSDT Scope
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

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:[e-mail]]
> Sent: Wednesday, March 26, 2008 1:53 PM
> To: Murari Sridharan; [e-mail]
> 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 <[e-mail]>
> To: Dirceu Cavendish <[e-mail]>; "[e-mail]" <[e-mail]>
> 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 [[e-mail]]
> Sent: Wednesday, March 26, 2008 1:15 PM
> To: Murari Sridharan; [e-mail]
> Subject: Re: [Iccrg] SSDT Scope
> Inline comments:
> 
> ----- Original Message ----
> From: Murari Sridharan <[e-mail]>
> To: Dirceu Cavendish <[e-mail]>; "[e-mail]" <[e-mail]>
> 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: [e-mail] [mailto:[e-mail]] On Behalf Of Dirceu Cavendish
> Sent: Wednesday, March 26, 2008 10:24 AM
> To: [e-mail]
> 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 <[e-mail]>
> To: Michael Welzl <[e-mail]>
> Cc: [e-mail]
> 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@...
> 
> Cheers,
> Lachlan
> 
> On 25/03/2008, Michael Welzl <[e-mail]<mailto:[e-mail]>> 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:
> >  > > [e-mail]<mailto:[e-mail]>
> >  > > 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
> >  [e-mail]<mailto:[e-mail]>
> >  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: [phone]    Fax: [phone]
> http://netlab.caltech.edu/lachlan
> 
> _______________________________________________
> Iccrg mailing list
> [e-mail]<mailto:[e-mail]>
> 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
> [e-mail]
> 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: [phone] Email: [e-mail]
Fax:   [phone] Web:   www.ikr.uni-stuttgart.de/en/~scharf