[Iccrg] ICCRG experimental CC reviews

[Lachlan Andrew]

Greetings Michael,

On 30/03/2008, Michael Welzl <michael.welzl at uibk.ac.at> wrote:
> > There were many stylistic issues the the CTCP draft, like not
>  > specifying parameter values,  the SHOUD/MUST/... terminology, what is
>  > normative vs informative..
>  >
>  > It would be good to write up a "how-to" for drafts, specifying what
>  > format the drafts should have, and what pitfalls to avoid.  That
>  > should speed the process up for future proposals.
>
> This is just an IETF standard, and must therefore already
>  exist somewhere... a few hints are at http://www.ietf.org/ID.html

Most of those guidelines are generic.  I meant things specific to the
call for new congestion controls.  See below.

If everyone submits initial draft meeting those criteria, then the
review process should be faster than the CTCP one was.

>  > Guidelines would help.  Perhaps we should specify that the draft
>  > should point to independent tests (on a non-buggy implementation).
>
> - that should be clear without a guideline IMO.

I was partly having a dig at the CTCP case, where they conscientiously
got SLAC to do some tests, but I believe it was on an early
implementation which had a major bug...  (Sorry Murari :)  For
example, a guideline could suggest that actual CWND histories be
plotted, as well as aggregate quantities, since this exposes many
possible bugs.


In case it helps, I'd suggest guidelines of:
1. As these are intended to be experimental RFCs, they should use
"SHOULD", "MUST" etc. to make clear which options are part of the
proposal.
2. They should specify the ranges of all parameters
3. There should be a clear statement of the algorithm, separated out
from justifications and motivations for the steps.  It should say when
each calculation is performed (once per CWND, once per ACK, at
timeout, ...)
4. Give a summary of the validation experiments, in addition to
informative references
5. The validation examples should plot some CWND histories, since
these would highlight many possibly bugs.
6. State which other options were used in conjunction with this in the
test (e.g. ABC, FRTO, ...)
7. Be careful about corner cases, such as
 a) clipping values to be non-negative
 b) whether values rounded to integers
 c) what to do after timeout or an idle connection
 d) replace phrases like "update x" by "set x to y".
8. Give an open-source implementation

Cheers,
Lachlan

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: +1 (626) 395-8820    Fax: +1 (626) 568-3603
http://netlab.caltech.edu/lachlan