On Tue, 29 May 2007, Mark Allman wrote:
Or do you mean that the proposers should do everything guidelines
(2), (5), (6) and (7) say, but shortcomings in the results of these
guidelines (e.g., proposal being only slightly more troublesome than
TCP) should not block the approval for widespread deployment in the
global Internet.
Yes. And, in re-reading the text I think it is clear.
I really can't untangle your comments in this area. If you have
specific suggestions for the text, please send them along.
-03 has:
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.
if the above is what you mean (and a proposer must really go through
everything you list, e.g., all the difficult environments as well), it
should be explicit, e.g.:
For other guidelines, i.e., (2), (5), (6), and (7), the author
must perform the suggested evaluations and provide recommended
analysis. 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.
My problem with existing text is that the referred guidelines use
wording "should do ...". Is it a "must do" or "may do" or something
in between? It should be more explicit. Text proposal above
interprets the shoulds as musts.
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.
What I try to say is that I can't figure out how operationally and
practically this could be achieved. Do you have examples in mind
how how this could apply in some specific scenario?
If not -- and it isn't a practical concern right now -- maybe we
should not overengineer the BCP to address best-effort vs
non-best-effort at all.
We didn't overengineer anything. We just said that the guideline
doesn't apply to non-BE cases. I can't understand your point here at
all. It is a simple statement of document scope.
Let's say I propose an informational RFC on congestion control and say
that it only applies to non-BE traffic. I don't have to make any of
the evaluations or analysis required by this draft. What's the
procedure for non-BE congestion control agorithms? I note that Lars's
ION does not mention that case.
In case there is no process to define non-BE congestion control
mechanisms at all (and the response would be "sorry, we don't support
that"), I have no problem.
In case there is some process with a lower bar, I'd have a problem,
because it would be possible to avoid the loops you have jump through
defined in this document by saying the CC algorithm applies to non-BE
traffic only, but in practice it would be end up deployed for BE
traffic as well.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf