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