Pekka-
> 1) the document appears to be slightly inconsistent wrt. what it's
> actually specifying, or there are nuances that may not be sufficiently
> well articulated. The introduction speaks of "..evaluating suggested
> CC algorithms that _significantly differ_ from the general CC
> principles outlined in [RFC2914]" (emphasis mine). The abstract does
> not mention 'significantly differ', and there is Rule (0) which seems
> to imply that this BCP could be applied both to the mechanisms that
> significantly differ from the RFC2914 guidelines and other congestion
> control mechanisms that still honor the RFC 2914 guidelines. Which is
> it? Does it have implications on the different 'tracks'?
I think you are reading a little much into this. I have just tweaked
the language in the document to include 'significantly different' in the
abstract and have changed (0) to this:
(0) Differences with Congestion Control Principles [RFC2914]
Proposed congestion control mechanisms that do should include a
clear explanation of the deviations from [RFC2914].
Is that more clear?
> Section 2 also says "Each alternate CC algorithm published is
> required to include a statement in the abstract indicating whether
> or not the proposal is considered safe for use on the Internet".
> Which documents this applies to is not clear enough: all IETF
> documents (through WG or through an AD)? IAB documents? IRTF
> documents? Individual RFC-editor submissions? It is not clear to me
> whether this document would have the authority (without explicit
> discussion within the RFC-editor publications constituencies) to
> impose further requirements on non-IETF document streams especially
> if it doesn't include 'Updates: 3932' in its header. I suspect the
> document only means to affect the IETF RFC publication stream but is
> not clear enough about it.
The document is intended to apply to IETF-produced documents. I added
the following to the 'Status' section. Does this help?
Note: we are not changing RFC publication process for non-IETF
produced documents (e.g., those from the IRTF or independent
RFC-Editor submissions). However, we would hope the guidelines in
this document inform the IESG as they consider whether to add a note
to such documents.
> Section 4 only talks of 'minimum requirements for a document to be
> approved as Experimental with approval for widespread deployment in
> the global Internet.' and further down "..approval for widespread
> deployment". What about the rest? Also, is omitting "in the global
> Internet" intentional? The flow of text doesn't go well as it is if
> that's the case, and if it's intentional, I'd rather use two
> entirely different wordings to make 'encouraged for widespread
> deployment' and 'encouraged for widespread deployment in the global
> Internet' more clearly distinct from each other. (Also, it isn't
> clear if the text is out of sync regarding guideline (2) compared to
> what it says in section 3 and what it says here.)
I agree the text is a little weird. I beat it a little. Does this:
The minimum requirements for approval for widespread deployment in
the global Internet include guidelines (1) on assessing the impact
on standard congestion control, (3) on investigation of the proposed
mechanism in a range of environments, guideline (4) on protection
against congestion collapse and guideline (8), discussing whether
the mechanism allows for incremental deployment.
For other guidelines, i.e., (2), (5), (6), and (7), evidence
that the proposed mechanism has significantly more problems
than those of TCP should be a cause for concern in approval for
widespread deployment in the global Internet.
work better?
> 2) the document requires that 'serious scientific study .. needs to have
> been done'. Yet there is no metrics an outsider could use to evaluate
> whether this test is met or not. It may be that TCP congestion
> control community has de-facto oral tradition what needs to be
> evaluated before an algorithm can be looked at seriously, but based on
> this proposed BCP, such metrics are not clear enough.
>
> Unless we can define clearer requirements and metrics for evaluation,
> perhaps the IETF should not attempt to make such an evaluation but
> leave it to the scientific community. I'm not sure how the IETF can
> liaise with the scientific community on that, e.g., whether it's
> possible to get a consensus statement from IRSG or an IRTF RG or
> something that could meet this requirement (if we don't want specify
> these criteria within the IETF).
The IETF and the IRTF have worked out a procedure for working on these
sorts of things (and Lars has documented it in an ION).
At the end of the day, IMO, the IETF needs to be able to make decisions
about new CC schemes. The document we wrote lays out a set of areas in
which authors of such proposals need to provide information to the IETF
community such that the IETF community can make sound engineering
judgments about the proposals. For a document that intends to live for
a long time it is pretty hard to go beyond "sound scientific evaluation"
and a big-picture list of *areas* where we know we want information.
> Also, checklist (2) has "A minimum goal for experimental mechanisms
> proposed for widespread deployment in the Internet should
> be that they do not perform significantly worse than TCP
> in these environments."
>
> However, 'these environments' refers to a non-exhaustive list of
> scenarios. This checklist does not provide adequate information to
> evaluate whether sufficient testing in the non-exhaustively defined
> "difficult environments" has taken place or not. I do not believe we
> can require assessments in various environments unless it's better
> specified what which environmets that various refers to.
You are right that we may want to better enumerate things. But, we
cannot necessarily illuminate all such environments that one might
encounter. I hacked out the following text (to be added, not replacing
anything that is there now).
While it is impossible to enumerate all possible "difficult
environments", we note that the IETF has previously grappled
with paths with long delays [RFC2488], high delay bandwidth
products [RFC3649], high packet corruption rates [RFC3155],
packet reordering [RFC4653] and significantly slow links
[RFC3150]. Aspects of alternate congestion control that impact
networks with these characteristics should be detailed.
Is that better?
> 3) The first evaluation criteria includes ".. should be evaluated when
> competing with standard IETF congestion control."
>
> What is that standard IETF congestion control referred to? RFC 793
> plus RFC 1122? These are the only two IETF _Standard_ specifications
> I can think of. Or does this include proposed standards as well? What
> constitutes "IETF congestion control" or "standard congestion control"
> (in another place) that a CC algorithm should be evaluated against?
>
> Please do not cite the TCP roadmap RFC on this. It's Informational
> and not an IETF consensus statement, and as such has no authority to
> define what constitutes "standard congestion control".
Added refs:
Proposed congestion control mechanisms should be evaluated when
competing with standard IETF congestion control
[RFC2581,RFC2960,RFC4340].
> 4) The first evaluation criteria also includes "We also note that this
> guideline does not constrain the fairness offered for non-best-effort
> traffic."
I don't understand your point here. All we are saying is that if---by
some means---we know that some flow is not best effort then it can be
subjected to some other criteria then it need not be constrained by the
guideline.
> 5) Normative references is empty, yet this is a BCP document which, among
> other things, referred to "standard congestion control" without
> providing a reference (as raised above). Please move some
> informational references over here and/or add applicable references.
I have now put the references to RFCs 2581, 2914, 2960 and 4340 under
normative references.
(And, splitting the references was the dumbest thing we ever did---it
causes no end to the haggling.)
> editorial
> ---------
>
> networks). Recent research has yielded many alternate congestion
> control schemes ([RFC3649], [HTCP], [FAST], [BIC], [CompoundTCP],
> [XCP], and many more). Using these new congestion control
>
> ==> please remove the references from the abstract per ID-nits.
Done.
> 2. Status
>
> ==> this title seems too short, and a somewhat longer and a more
> descriptive one would be useful. Actually the section seems to be a
> mix and match of different topics and a better organization might help
> the document considerably. E.g., if there was a numbered list or
> subsection of different "publication paths" and descriptions of each
> the scope of the document and the intent of this section would likely
> be much clearer.
I changed the title to "Document Status", but I am not inclined to
re-arrange it further because lots of people have read this now and
nobody has complained.
The major caveat here is that *I* hacked out the changes described
above. Sally may want to wordsmith or just plain disagree.
allman
Attachment:
pgpKzFBro9ndJ.pgp
Description: PGP signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf