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

[Mark Allman]

> 	  - 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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070530/73c166d6/attachment.bin