Mark, et al,
If I concentrate on one item. And yes, I read this
phase in the document. The SHOULD type terminology is
what I thought is standard. I prefer MUST instead, but I don't
know what the implications are of violation support of prior
violations of previous MUSTs.
> > - ALL new CC algorithms SHOULD pass through a preliminary
> > experimental stage..
>
> The document says:
>
> Following the lead of HighSpeed TCP [RFC3649], alternate congestion
> control algorithms are expected to be published as "Experimental"
> RFCs until such time that the community better understands the
> solution space.
>
then
> control algorithms are expected to be published as "Experimental"
to
control algorithms SHOULD be published as "Experimental"
And why wouldn't a minimum timeframe be specified? And items
listed that state how an implementation exits this experimental
phase, versus subjective evaluation. Ie, a vote of a working
group that requires xx% acceptance. After a xyz CC algor
is automaticlly accepted for evaluation, a new mail alias
COULD be generated for all feedback. ...
> ... until such time that the community better understands the
> solution space.
Secondly, I have never understood the non-requirment
of a REFERENCE implementation. The Reference implmentation
IMO, doesn't have to be source.
Lastly, should a accepted CC algor ever be re-reviewed
to see if it has aged well??? And needs updating.
Mitchell Erblich
PS: a few inline for clarifications..
---------------
Mark Allman wrote:
>
> > - two or more implimentations using a new alternate cc algorithm
> > could be used as interoperability against each other and another
> > cc algor..
> >
> > - if possible, a Linux, xBSD, etc public reference should be
> > available,
>
> This is part of the standards process already. (Not the public
> reference business, but that seems like a whole different can of worms
> than we are working on.)
>
> > - experiences using the new cc algorithm should be available,
>
> That is what the guidelines in the document are about.
>
> > - ALL new CC algorithms SHOULD pass through a preliminary
> > experimental stage..
>
> The document says:
>
> Following the lead of HighSpeed TCP [RFC3649], alternate congestion
> control algorithms are expected to be published as "Experimental"
> RFCs until such time that the community better understands the
> solution space.
>
> > 2) What is the expected consequences if a private entitity
> > implements a private/IP CC algorithm that is unfair, etc..
>
> That is out of scope for this document. Clearly what to do about
> "cheaters" is a worthy thing to think / write about. But, this document
> is guidelines for those who want to bring their work to the IETF
> community.
>
> > 3) Classification (ordering) of a CC algorithm that is used
> > as a TCP option, so two endpoints can determine which
> > CC algorithm is used at each endpoint,
>
> This is a detail not a guideline.
>
> > 4) Support for a CC algorithm in one environment, ie LFN..
>
> I don't understand what you are getting at here. But, see guideline
> (2).
Can a implimentation be offered to work in ONLY 1 environment?
>
> > 5) Well known TCP CC algorithms that may use non-standard options:
> > ie: 10 Dup-ACKs for a fast re-xmit..
>
> What does this mean? (I mean, I understand that you are talking about
> non-standard stacks. But, I have no idea what your point here is as it
> relates to the i-d.)
All implementations that I have worked on, have a stated
set of configurables with default values. If a well known accepted
implimentation is significantly modified, at what point is it
considered a new implementation. Ie: Removing fast acks in
small in-flight segment environments
>
> > 6) Specifiying a minimum inter-packet gap based on recent history
> > to minimize ANY CC alg from implmenting say a 100 seg burst,
> > from a non-slow start re-start...
>
> More details that are fine to think about but are out of scope for this
> document.
>
> Folks- this document has been voted on by the IESG and has all but
> passed. We have made a few tweaks from IESG comments and Pekka's
> comments. Clearly big issues can and should still be addressed, but
> this document is seemingly past "open season" on small things.
>
> allman
>
> ------------------------------------------------------------------------
> Part 1.2Type: application/pgp-signature
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf