> > (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? > > Yes (though '..that do should..' seemed weird on the first read).
I have fixed this (Sally caught it, too).
> 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.
About this 'rock fetch' stuff (in terms of metrics and environments): We
do not solve the problem you outline ('go fetch another rock'). But, we
did not aim to solve that problem and we cannot solve that problem in
this document. We cannot enumerate all environments or all metrics that
might be of interest in the future. I sympathize with your desire for a
simple checklist that one can go through and be "ready", but this is all
much too complicated for a simple checklist. (Consider for a moment the
additional metrics that something like XCP brought to the table that
were not germane previously.) It is not clear to me that we should
pretend we can list metrics. Note that we have not made this 'rock
fetch' problem any worse, either. I.e., it exists for any new CC scheme
that would be run through without this document the same as with this
document.
I am not planning to further change the document with respect to adding
metrics or more about environments unless lots of people start yelling.
This document has been widely read at this point and as far as I know
nobody else has had this concern. (We can call the consensus 'rough' if
you prefer.)
> >> 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.
allman
pgpOP9EI2wHYf.pgp
Description: PGP signature
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
