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
pgpIuqcJaiMKx.pgp
Description: PGP signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf