[Iccrg] Procedure for obtaining ICCRG reviews
doug.leith at nuim.ie
Fri Aug 3 09:51:41 BST 2007
It might be worth trying to clarify what is meant by "safe to deploy"
when making one of these recommendations. For example, one argument
is that inclusion of
timeout functionality with backoff of the timeout threshold is enough
for "safety" since it will prevent complete congestion collapse (at
high loss rates operation will revert back to standard TCP
behaviour). Is this enough ? In any case, its probably a good idea
to distinguish "safety" from "performance" per se.
On 3 Aug 2007, at 08:46, Michael Welzl wrote:
> Hi all,
> Before I use it for the CTCP draft (which is the only one
> on our table so far), I would like to solicit comments
> on the email which I'm planning to use for obtaining
> In particular, I wonder what you think about the final
> recommendation idea, which I derived from section 2 of
> draft-ietf-tsvwg-cc-alt-04.txt - any suggestions are
> Dear all,
> As you probably know, ICCRG has agreed to obtain reviews
> on experimental congestion control proposals before they
> are brought to the IETF (specifically the TCPM group). While
> the competence to actually decide about acceptance or not is
> with TCPM, it is expected that they will take our reviews
> into account. This process is outlined here:
> Right now, we are looking for reviews on draft-xyz:
> We would like to get feedback within 2 1/2 months
> (earlier if possible).
> If you're interested in doing a review, please send a note
> to Wes and me. Reviews can be sent to the list, or directly
> to us for anonymization before reflecting them out to the
> list, if desired.
> Reviewers are strongly advised to:
> * read draft-ietf-tsvwg-cc-alt-04:
> * consider not only the draft alone, but also papers referenced
> therein, where the authors should have carried out a performance
> evaluation of their mechanism, including studies which show the
> impact of the new mechanism on standard TCP. When looking at
> such studies, this document is recommended to be used for guidance:
> Reviews should include one of the following final recommendations:
> * Experimental 1:
> The proposed mechanism is judged to be safe to deploy for
> best-effort traffic in the global Internet and further
> investigated in that environment.
> * Experimental 2 A:
> While promising, the proposed mechanism is not deemed safe
> enough for widespread deployment as best-effort traffic on
> the Internet, but can be specified to facilitate investigations
> in simulation, testbeds, or controlled environments.
> * Experimental 2 B:
> The IETF does not yet have sufficient understanding to decide
> if the algorithm is or is not safe for deployment on the Internet.
> * Informational:
> The proposed mechanism does not meet the criteria for recommending
> publication of the draft as an Experimental RFC. It should be
> considered for publication as an Informational RFC for the benefit
> of the IETF and IRTF communit, provided that it carries an
> explicit warning against using the scheme in the global Internet.
> * Not ready:
> The draft is not ready for publication as an Experimental or
> Informational RFC.
> A review can be as short as a selection from the list of options,
> although preferably it would include at least some brief
> discussion or justification. No matter how long the feedback
> is, we expect reviewers to have thoroughly read all the
> necessary material.
> Thanks in advance to anyone who volunteers!
> Iccrg mailing list
> Iccrg at cs.ucl.ac.uk
More information about the Iccrg