Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (Specifying New Congestion Control Algorithms) to BCP

[Pekka Savola <pekkas at netcore.fi>]

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.org
https://www1.ietf.org/mailman/listinfo/ietf