Re: [dccp] Mul-TFRC (draft-welzl-multfrc-00)

[Pasi Sarolahti]

Hi,

Looking at the current charter, the goals set for the DCCP working  
group have been mostly accomplished, apart from "guidance to potential  
users". I guess technically it would be possible to re-charter the  
working group to something like "DCCP maintenance and New CCIDs", but  
it is unclear to me how much there is demand for such re-chartering at  
the moment. Maybe this is something we can shortly discuss in  
Hiroshima meeting.

I have sympathies for using DCCP as a framework for experimenting with  
new congestion control algorithms, and it would be nice if such  
experimentations did not require heavyweight administrative process.  
One thing we might do is to give guidelines for conducting such  
experimentations, for example regarding how to use the experimental  
CCID range defined in RFC 4340.

The current MulTFRC specifies a congestion control method, not a CCID.  
So to me ICCRG would not seem totally wrong place to do such work.  
RFCs can come out of RGs, too, right?

- Pasi


On Oct 13, 2009, at 12:25 PM, Gorry Fairhurst wrote:


Tom,

I don't see anything in the Charter about using DCCP as a platform  
for experimental standards - although clearly you *could* do that  
and there are codepoints for experimentation, and that is fine. I  
was urging restraint in standardising these new CCIDs.

I also recall that ICCRG would be the first point point of review  
for transport protocols that were not already deployed, or needed  
review prior to being taken to a WG. I don't recall a special case  
for ICCRG in the DCCP charter text.

Gorry

Phelan, Tom wrote:
Hi Gorry,
It's been a while since I read the DCCP charter carefully, but I  
seem to
remember something about cooperating with ICCRG to experiment with  
new
congestion control protocols.  My take on that is that we should
consider creating experimental-track RFCs for protocols that have  
some
level of support from the ICCRG (we can discuss what that level of
support should be).
One of the benefits of doing this through DCCP is that the congestion
control protocol developer can concentrate on just that and let DCCP
carry the burden of the rest of what makes a transport protocol.   
This
seems to me to be good for the CC developers and good for DCCP, even
though it won't necessarily lead to production deployment of DCCP
(unless one of these CC protocols is a hit :-)).
Tom P.
-----Original Message-----
From: dccp-boun...@ietf.org [mailto:dccp-boun...@ietf.org] On Behalf
Of
Gorry Fairhurst
Sent: Wednesday, October 07, 2009 2:53 AM
To: dccp >> 'dccp' working group
Subject: [dccp] Mul-TFRC (draft-welzl-multfrc-00)


Pasi asked for comments on MulTFRC...

I don't see the application (yet) that will drive this forward and  
the
user community that wants this to deliver whatever they need to  
do. If
people have potential uses for this, then it would be really good to
hear them.

My take is that this is an interesting piece of research, and it  
could
be safe - I think it's good to experiment with new CC methods,  
however
I
don't see the need to standardise each method, I question whether  
this
will encourage production use of DCCP. In this case, I'm not yet
persuaded there is a standardisation need.

Gorry