Hi Wesley, I like the sound of that request for information proposal. I think the bar for "safety" of a DCCP experimental CC draft is a lot lower than it is for TCP. Mostly I think that we'd just want to know that there are people who would seriously review the draft before we make it a WG draft. Tom P. > -----Original Message----- > From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf Of > Eddy, Wesley M. (GRC-MS00)[Verizon] > Sent: Tuesday, October 13, 2009 4:03 PM > To: dccp >> 'dccp' working group > Subject: Re: Mul-TFRC (draft-welzl-multfrc-00) > > I'm guessing people are thinking of this ION: > http://wiki.tools.ietf.org/group/iesg/trac/browser/ions/approved/ion-tsv - > alt-cc.txt > > Previously, this course of action (using ICCRG to vet "safety" of > a proposed Experimental document before progressing in IETF) was > used with Compound TCP, CUBIC, and H-TCP. It has been much slower > of a process than expected, and though some positive results and > interactions have come about, it hasn't been an effective way to get > Experimental documents published by IETF WGs yet. > > Based on that experience, I'd probably do things slightly differently > in the future ... leaving dates open-ended is definitely one thing to > avoid. Bounding the dates gives "making progess" priority over having > a length evaluation, but after discussions in the ICCRG, I think a lot > of people seem to be comfortable with that. > > If something like this is to be done with MulTFRC for DCCP, I would > suggest that something like a "request for information" be sent from > coordinated DCCP and ICCRG chairs to the ICCRG with bounded timeframe > (like 2 months) for comments to come in. At the end of that timeframe, > someone from ICCRG could post a summary write-up to DCCP. > > Just a suggestion ... as an ICCRG co-chair, I'd be willing to help with > this. We'd have to check with the other ICCRG co-chair too :). > > --------------------------- > Wes Eddy > Network & Systems Architect > Verizon FNS / NASA GRC > Office: (216) 433-6682 > --------------------------- > > >-----Original Message----- > >From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf Of > >Gorry Fairhurst > >Sent: Tuesday, October 13, 2009 3:26 PM > >To: Phelan, Tom > >Cc: dccp >> 'dccp' working group > >Subject: Re: Mul-TFRC (draft-welzl-multfrc-00) > > > > > >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. > >>
