Subject: Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (SpecifyingNewCongestion Control Algorithms) to BCP

From: Erblichs <[email-masked]>
Date: Thu, 31 May 2007 11:46:51 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf