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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf