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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf