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

From: Erblichs <[email-masked]>
Date: Wed, 30 May 2007 16:46:00 -0700

Mark Allamn,

	I always have a "internal fight" when I read these
	documents as whether they are meant as a BCP type
	document or...

	So, if I can add my thoughts..

	1) Architecture design and implementation can be two completely
	   different items for acceptance criteria. Thus, I might propose
	   the floowing items:

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

	  - experiences using the new cc algorithm should be available,

	  - ALL new CC algorithms SHOULD pass through a preliminary
	    experimental stage..

	2) What is the expected consequences if a private entitity
	   implements a private/IP CC algorithm that is unfair, etc..

	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,

	4) Support for a CC algorithm in one environment, ie LFN..

	5) Well known TCP CC algorithms that may use non-standard options:
	ie: 10 Dup-ACKs for a fast re-xmit..

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

	Mitchell Erblich
	-----------------

Mark Allman wrote:
> 
> >      For other guidelines, i.e., (2), (5), (6), and (7), the author
> >      must perform the suggested evaluations and provide recommended
> >      analysis.  Evidence that
> >      the proposed mechanism has significantly more problems than those of
> >      TCP should be a cause for concern in approval for widespread
> >      deployment in the global Internet.
> 
> Looks OK to me.  I have incorporated it, modulo comments from Sally.
> 
> As for the non-BE stuff: This document is a no-op.  But, why is that an
> issue?  The IETF would have to grapple with the non-BE case just as it
> does today (i.e., without a set of guidelines).  This one document does
> not need to solve all the world's problems.  If you want to write a
> document about how the IETF should handle non-BE congestion control
> proposals, I think that'd be fine.  And, again, I am not hearing outcry
> on this point so I think the document is fine (even if the consensus on
> this one point is not completely 'smooth').
> 
> Thanks,
> allman
> 
>   ------------------------------------------------------------------------
>    Part 1.2Type: application/pgp-signature

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf