Code change:
3. <ins> 3.1. This document does not specify specific evaluation methods, short of internet-scale deployment and measurement, to test the criteria described below.  There are multiple possible approaches to evaluation.  Each has a role, and the most appropriate approach depends on the criteria being evaluated and the maturity of the specification. For many algorithms, an initial evaluation will consider individual protocol mechanisms in a simulator to analyse their stability and safety across a wide range of conditions, including overload.  For example, RFC8869 describes evaluation test cases for interactive real-time media over wireless networks.  Such results could also be published or discussed in IRTF research groups, such as ICCRG and MAPRG. Before a proposed congestion control algorithm is published as an Experimental or Standards Track RFC, the community SHOULD gain practical experience with implementation and experience using the algorithm.  Where there is implementation by independent teams, this can help provide assurance that a specification has avoided assumptions or ambiguity.  An independent evaluation by multiple teams helps provide assurance that the design meets the evaluation criteria, and can assess typical interactions with other traffic. This evaluation could use an emulated laboratory environment or a controlled experiment (within a limited domain or at Internet-scale). Evidence of results is normally considered by the working group in deciding if a specification is ready for publication and ought to be documented in any request for the working group to publish the specification. 3.2. </ins> This document applies to proposals for congestion control algorithms that seek Experimental or Standards Track status.  Evaluation of both cases involves the same questions, but with different expectations

Related discussion:
text: This responds to an AD question in review. The text is proposed to shed some light on how to go about evaluating a new CC algorithm, and when to use different approaches. It could be enough, or it could be improved, please think about how best to say this.
Thanks for this.. this looks like very good expression of the expectations on how one can think of evaluating the candidate congestion control algorithms without going into lengthy details. For the sake of clarity, it seems like the word "overload" (in the quoted sentence below) needs some explanation on what exactly we mean here - I am assuming we are referring to typical congestion scenarios on the path due to packet inflow and out flow mismatch in a bottleneck network node. >>"For many algorithms, an initial evaluation will consider individual protocol mechanisms in a simulator to analyse their stability and safety across a wide range of conditions, including overload".
overload, aka a lot more traffic than the path can handle... rather than typical congestion. Martin may have suggested wording...
While section 5 expects to do well-round of evaluations, it does not specify where or how to do the evaluation. Does the congestion control proposals provide the evaluation results in a simulator or in a real lab setup or in a controlled part of the Internet or over the Internet? While it is understandable that an accurate description on the evaluation environment is tough to define but the specification should at least mention what is good enough environment to evaluation on, or state it does not really matter.
See below:On 27 May 2024, at 10:50, Zaheduzzaman Sarker NAME wrote: While section 5 expects to do well-round of evaluations, it does not specify where or how to do the evaluation. Does the congestion control proposals provide the evaluation results in a simulator or in a real lab setup or in a controlled part of the Internet or over the Internet? While it is understandable that an accurate description on the evaluation environment is tough to define but the specification should at least mention what is good enough environment to evaluation on, or state it does not really matter. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: NAME I am not sure how we add guidance … surely all of these method can be appropriate (more so for some of the evaluations) when bringing new work to the IETF.