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
