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