Hi Pasi, The charter that's up on the DCCP page is _not_ the current charter. The _real_ charter is closer to the spirit of "DCCP maintenance and new CCIDs", although, if I recall correctly, it's maybe more like "DCCP maintenance and enhancements that will broaden the usability". I see Lars has sent a note to the secretariat -- we'll see if it gets fixed. Tom P. > -----Original Message----- > From: Pasi Sarolahti [mailto:pasi.sarolahti@xxxxxx] > Sent: Tuesday, October 13, 2009 4:46 PM > To: gorry@xxxxxxxxxxxxxx > Cc: Phelan, Tom; dccp >> 'dccp' working group > Subject: Re: Mul-TFRC (draft-welzl-multfrc-00) > > 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-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf > >> Of > >>> Gorry Fairhurst > >>> Sent: Wednesday, October 07, 2009 2:53 AM > >>> To: dccp >> 'dccp' working group > >>> Subject: 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 > >
