> - 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
Attachment:
pgp7A3QUr0DwL.pgp
Description: PGP signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf