> - 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).
> 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.)
> 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
pgpXfV319kYv7.pgp
Description: PGP signature
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
