Code change:
I resisted the urge to resolve other issues with this, so there are a bunch of TODOs in the text. Most of the big blocks of text are moved from elsewhere in the document.
The guidelines overlap in odd ways. The first one is essentially TCP-friendliness, and I guess it's implied to be talking about "normal" wired networks. Then different guidelines say the algorithm should be evaluated with all sorts of environments and/or link parameters, presumably for friendliness. Then, in "Minimum Requirements" some of these are listed as mandatory to satisfy, and the rest as something the submitter has to report on, but the community may decide to accept even if it's bad. There are several different concepts that are being muddled here. Alternatively, we can structure it as follows: (A) Metrics to evaluate Does the new algorithm match its share of the existing bottleneck bandwith better than existing algorithms? (not underutilizing, not bufferbloating or congestion collapsing) in isolation or with multiple flows? Are flows using widely deployed algorithms not severely degraded by the introduction of the new algorithm? Is there a plausible incremental deployment plan? Something about short flows? (B) Mandatory Domains: must answer positively to (A) Wired networks, "normal" range of BDPs Wireless networks, "normal" range of BDPs (loss & jitter) Internet-scale deployment is sufficient for this? (C) Optional Domains: must evaluate (A) & report IoT Satellite Misbehaving nodes Response to sudden & transient events Tunnels for explicit-signal protocols Extreme packet reordering
I agree we need to restructure, I like the idea of A. I think defining heterogeneity in B is likely helpful - although we really ought to stop using "bandwidth" when we mean "capacity" - because it really confuses SDOs that actually do cap[acity v bandwidth tradeoffs:-) I'll fight that Internet-Scale deployment is sufficient;-). That plays to the big operators, and I do not like that. It worries me quite a lot that we target "normal BDPs" - that's not something I would welcome. It places all satellite outside normal, which again, I don't like - some satellite is definitely odd, but I'd really like to see broadband services as "normal", if nothing else, to include those people who can only use this technology. So, main question first: can we factor the last section as different in a particular perspective, rather than "labelling" networks as optional to support? i.e. XXXX is a property, and IoT is an example, transients and abrupt capacity variation is an example of radio networks; etc.?
I agree that we need a better structure. Including having actual subsections per issue, rather than the current list format. Two points: short flows, and transient events. Short flows are pretty much the norm, with reports of 90% of connections never going out of slow start. There is an associated problem: capacity discovery algorithm like slow start will rapidly increase the amount of data sent on a path, with a high potential for disrupting current users of that path. That's not good. There are potentials solutions such as quickly evaluating the capacity (e.g., packet pair, squirting, variants), remembering past connections (careful resume), or potentially getting input from the network (maybe something like Prague/ECN). These solutions have been explored for "special" links (satellite, deep space), but the problem is not just special links. I would like to see that discussed in the "main" section (A). Transients are also the norm. Congestion control is a form of control algorithm, and control algorithms must absolutely deal with transients. For example, if we deal with wireless, we need to deal with "entering a tunnel" -- and exiting. We may want to deal with . That should belong to the core (A), not the "weird configuration" (C).
Wait to land PRs, then do this with no substantive change, then do other PRs -- this change will be editorially disruptive.
I like the flow after this refactoring!Good to merge, the text here looks good to me. There are still things to think about, but these are probably best down on the basis of the entire document.

Related discussion:
text: these guidelines should not be considered as an all-encompassing check-list. <del> Differences with Congestion Control Principles Proposed congestion control mechanisms should include a clear explanation of the deviations from RFC2914. Impact on existing deployments of TCP RFC9293, SCTP RFC9260, DCCP RFC4340, and QUIC RFC9000. Proposed congestion control mechanisms should be evaluated when competing with standard IETF congestion control RFC5681, RFC9260, RFC4340, RFC9002, RFC9438.  Alternate congestion controllers that have a significantly negative impact on traffic using standard congestion control may be suspect and this aspect should be part of the community's decision making with regards to the suitability of the alternate congestion control mechanism.  The community should also consider other non-standard congestion controls known to be widely deployed, We note that this bullet is not a requirement for strict Reno- or Cubic- friendliness as a prerequisite for an alternate congestion control mechanism to advance to Experimental.  As an example, HighSpeed TCP is a congestion control mechanism that is Experimental, but that is not TCP-friendly in all environments. When a new algorithm is deployed, the existing major deployments need to be considered to avoid severe performance degradation.  We also note that this guideline does not constrain the interaction with non-best-effort traffic. As an example from an Experimental RFC, fairness with standard TCP is discussed in Sections 4 and 6 of RFC3649 (HighSpeed TCP) and using spare capacity is discussed in Sections 6, 11.1, and 12 of RFC3649. Wireless links While the early Internet was dominated by wired links, the properties of wireless links have become extremely important to Internet performance.  In particular, congestion controllers should be evaluated in situations where some packet losses are due to radio effects, rather than router queue drops; the link capacity varies over time due to changing link conditions; and media access delays and link-layer retransmission lead to increased jitter in round-trip times.  See RFC3819 and Section 16 of Tools for further discussion of wireless properties. Difficult Environments. The proposed algorithms should be assessed in difficult environments.  We note that there is still much to be desired in terms of the performance of TCP in some of these difficult environments.  For congestion control mechanisms with explicit feedback from routers, difficult environments can include paths with non-IP queues at layer-two, IP tunnels, and the like.  A minimum goal for experimental mechanisms proposed for widespread deployment in the Internet should be that they do not perform significantly worse than TCP in these environments. While it is impossible to enumerate all the possible "difficult environments", we note that the IETF has previously grappled with paths with long delays RFC2488, high delay bandwidth products RFC3649, high packet corruption rates RFC3155, packet reordering RFC4653, and significantly slow links RFC3150.  Aspects of alternate congestion control that impact networks with these characteristics should be detailed. As an example from an Experimental RFC, performance in difficult environments is discussed in Sections 6, 9.2, and 10.2 of RFC4782 (Quick-Start). Investigating a Range of Environments. Similar to the last criteria, proposed alternate congestion controllers should be assessed in a range of environments.  For instance, proposals should be investigated across a range of capacities, round-trip times, levels of traffic on the reverse path, and levels of statistical multiplexing at the congested link.  Similarly, proposals should be investigated for robust performance with different queueing mechanisms in the routers, especially Random Early Detection (RED) FJ03 and Drop-Tail.  This evaluation is often not included in the internet-draft itself, but in related papers cited in the draft. A particularly important aspect of evaluating a proposal for standardization is in understanding where the algorithm breaks down.  Therefore, particular attention should be paid to characterizing the areas where the proposed mechanism does not perform well. As an example from an Experimental RFC, performance in a range of environments is discussed in Section 12 of RFC3649 (HighSpeed TCP) and Section 9.7 of RFC4782 (Quick-Start). Protection Against Congestion Collapse The alternate congestion control mechanism should either stop sending when the packet drop rate exceeds some threshold RFC3714, or should include some notion of "full backoff".  For "full backoff", at some point the algorithm would reduce the sending rate to one packet per round-trip time and then exponentially backoff the time between single packet transmissions if congestion persists.  Exactly when either "full backoff" or a pause in sending comes into play will be algorithm-specific.  However, as discussed in RFC2914, this requirement is crucial to protect the network in times of extreme congestion. If "full backoff" is used, this bullet does not require that the full backoff mechanism must be identical to that of TCP RFC2988. As an example, this bullet does not preclude full backoff mechanisms that would give flows with different round- trip times comparable caapcity during backoff. Protection Against Bufferbloat The alternate congestion control mechanism should reduce its sending rate if the round trip time (RTT) significantly increases. Exactly how the algorithm reduces its sending rate is algorithm specific. Bufferbloat Bufferbloat refers to the building of long queues in the network.  Many network routers are configured with very large buffers.  If congestion starts happening, classic TCP congestion control algorithms RFC5681 will continue sending at a high rate until the buffer fills up completely and packet losses occur. Every connection going through that bottleneck will experience high latency.  This is particularly bad for highly interactive applications like games, but it also affects routine web browsing and video playing. This problem became apparent in the last decade and was not discussed in the Congestion Control Principles published in September 2002 RFC2914.  The classic congestion control algorithm RFC5681 and the widely deployed Cubic algorithm RFC9438 do not address it, but newly designed congestion control algorithms have the opportunity to improve the state of the art. Fairness within the Alternate Congestion Control Algorithm. In environments with multiple competing flows all using the same alternate congestion control algorithm, the proposal should explore how the capacity is shared among the competing flows. Test for the effect of path changes An IETF transport is not tied to a specific Internet path.  The set of routers forming a path can and do change with time, this will also cause the properties of the path to change with respect to time.  New CCs MUST evaluate the impact of changes in the path, and be robust to changes in path characteristics on the interval of common Internet re-routing intervals. Utilising More than one Path. Multipath transport protocols permit more than one path to be differentiated and used by a single connection at the sender.  A multipath sender can schedule which packets travel on which of its active paths.  This enables a tradeoff in timeliness and reliability. </del> <ins> When considering a new congestion control proposal, the community MUST consider the following criteria.  These criteria will be evaluated in various domains (see general-use and special-cases). 3.1. The following criteria evaluate the proposed algorithm when one or more flows using that algorithm share a bottleneck link, with no other algorithms operating. 3.1.1. The alternate congestion control mechanism should either stop sending when the packet drop rate exceeds some threshold RFC3714, or should include some notion of "full backoff".  For "full backoff", at some point the algorithm would reduce the sending rate to one packet per round-trip time and then exponentially backoff the time between single packet transmissions if congestion persists.  Exactly when either "full backoff" or a pause in sending comes into play will be algorithm-specific.  However, as discussed in RFC2914, this requirement is crucial to protect the network in times of extreme congestion. If the result of full backoff is used, this test does not require that the full backoff mechanism must be identical to that of TCP RFC2988.  As an example, this bullet does not preclude full backoff mechanisms that would give flows with different round- trip times comparable capacity during backoff. 3.1.2. The alternate congestion control mechanism should reduce its sending rate if the round trip time (RTT) significantly increases.  Exactly how the algorithm reduces its sending rate is algorithm specific, but see RFC8961 and RFC8085 for requirements. Bufferbloat Bufferbloat refers to the building of long queues in the network.  Many network routers are configured with very large buffers.  If congestion starts happening, classic TCP congestion control algorithms RFC5681 will continue sending at a high rate until the buffer fills up completely and packet losses occur.  Every connection going through that bottleneck will experience high latency.  This adds unwanted latency that impacts highly interactive applications like games, but it also affects routine web browsing and video playing. This problem became apparent in the last decade and was not discussed in the Congestion Control Principles published in September 2002 RFC2914.  The classic congestion control algorithm RFC5681 and the widely deployed Cubic algorithm RFC9438 do not address it, but newly designed congestion control algorithms have the opportunity to improve the state of the art. 3.1.3. When multiple competing flows all using the same alternate congestion control algorithm, the proposal should explore how the capacity is shared among the competing flows. 3.1.4. (TODO: Discuss short and long flows) 3.2. These criteria evaluate the interaction of the proposal with commonly deployed congestion controls. 3.2.1. Evaluate the impact on TCP RFC9293, SCTP RFC9260, DCCP RFC4340, and QUIC RFC9000. Proposed congestion control mechanisms should be evaluated when competing with standard IETF congestion control RFC5681, RFC9260, RFC4340, RFC9002, RFC9438.  Alternate congestion controllers that have a significantly negative impact on traffic using standard congestion control may be suspect and this aspect should be part of the community's decision making with regards to the suitability of the alternate congestion control mechanism.  The community should also consider other non-standard congestion controls known to be widely deployed, We note that this bullet is not a requirement for strict Reno- or Cubic- friendliness as a prerequisite for an alternate congestion control mechanism to advance to Experimental.  As an example, HighSpeed TCP is a congestion control mechanism that is Experimental, but that is not TCP-friendly in all environments.  When a new algorithm is deployed, the existing major deployments need to be considered to avoid severe performance degradation.  We also note that this guideline does not constrain the interaction with non-best- effort traffic. As an example from an Experimental RFC, fairness with standard TCP is discussed in Sections 4 and 6 of RFC3649 (HighSpeed TCP) and using spare capacity is discussed in Sections 6, 11.1, and 12 of RFC3649. 3.2.2. (TODO: Clarify that real time congestion controls are included, with allowances for the poor documentation / open source availability of these) 3.2.3. (TODO: Discuss short and long flows) 3.3. 3.3.1. Proposed congestion control mechanisms SHOULD include a clear explanation of the deviations from RFC2914. 3.3.2. The proposal should discuss whether the alternate congestion control mechanism allows for incremental deployment in the targeted environment.  For a mechanism targeted for deployment in the current Internet, it would be helpful for the proposal to discuss what is known (if anything) about the correct operation of the mechanism with some of the equipment installed in the current Internet, e.g., routers, transparent proxies, WAN optimizers, intrusion detection systems, home routers, and the like. As a similar concern, if the alternate congestion control mechanism is intended only for specific environments (and not the global Internet), the proposal should consider how this intention is to be carried out.  The community will have to address the question of whether the scope can be enforced by simply stating the restrictions or whether additional protocol mechanisms are required to enforce the scoping.  The answer will necessarily depend on the change being proposed. As an example from an Experimental RFC, deployment issues are discussed in Sections 10.3 and 10.4 of RFC4782 (Quick-Start). 4. The criteria in evaluation-criteria will be evaluated in the following scenarios.  Unless a proposal is explicitly forbidden on the public internet, the community MUST find that it meets the criteria in these scenarios for the proposal to progress. The evaluation in each scenario should occur over a representative range of bandwidths, delays, and queue depths.  Of course, the set of parameters representative of the public internet will change over time. These criteria are meant to capture a statistically dominant set of internet conditions.  In the case that the algorithm has been tested at internet scale, the results from that deployment are often useful for answering these questions. 4.1. (TODO: Describe properties of wired networks.) Proposals should be investigated for robust performance with different queueing mechanisms in the routers, especially Random Early Detection (RED) FJ03 and Drop-Tail.  This evaluation is often not included in the internet-draft itself, but in related papers cited in the draft. 4.2. While the early Internet was dominated by wired links, the properties of wireless links have become extremely important to Internet performance.  In particular, congestion controllers should be evaluated in situations where some packet losses are due to radio effects, rather than router queue drops; the link capacity varies over time due to changing link conditions; and media access delays and link-layer retransmission lead to increased jitter in round-trip times.  See RFC3819 and Section 16 of Tools for further discussion of wireless properties. 5. The criteria in evaluation-criteria will be evaluated in the following scenarios, unless the proposal specifically presents its use in a scenario.  The community MAY allow a proposal to progress even if the criteria indicate an unsatisfactory result for these scenarios. In general, measurements from internet-scale deployments will not expose the properties of operation in these scenarios, as they are statistically small. 5.1. (TODO: Write this section) </ins> <del> A concurrent multipath transport protocol simultaneously schedules flows to aggregate the capacity across multiple paths.  The Internet provides no guarantee that different paths (e.g., using different endpoint addresses) are disjoint.  This has additional implications: New CCs MUST evaluate the potential harm to other flows when the multiple paths share a common congested bottleneck (or share resources that are coupled between different paths, such as an overall capacity limit), and SHOULD consider the fairness with other flows.  Synchronisation of CC mechanisms (e.g., where multiple flows change their behaviour on similar timeframes) can also contribute to harm and/or reduce fairness, these effects also ought to be evaluated.  At the time of writing, there are no IETF standards for concurrent multipath congestion control in the general Internet. </del> <ins> 5.2. </ins> <del> Performance with Misbehaving Nodes and Outside Attackers. </del> <ins> Satellite links often have delays longer than typical for wired paths RFC2488 and high delay bandwidth productsRFC3649. </ins> <del> The proposal should explore how the alternate congestion control mechanism performs with misbehaving senders, receivers, or routers.  In addition, the proposal should explore how the alternate congestion control mechanism performs with outside attackers.  This can be particularly important for congestion control mechanisms that involve explicit feedback from routers along the path. </del> <ins> 5.3. </ins> <del> As an example from an Experimental RFC, performance with misbehaving nodes and outside attackers is discussed in Sections 9.4, 9.5, and 9.6 of RFC4782 (Quick-Start).  This includes discussion of misbehaving senders and receivers; collusion between misbehaving routers; misbehaving middleboxes; and the potential use of Quick-Start to attack routers or to tie up available Quick- Start bandwidth. </del> <ins> The proposal should explore how the alternate congestion control mechanism performs with non-compliant senders, receivers, or routers. In addition, the proposal should explore how the alternate congestion control mechanism performs with outside attackers.  This can be particularly important for congestion control mechanisms that involve explicit feedback from routers along the path. </ins> <del> Responses to Sudden or Transient Events. </del> <ins> As an example from an Experimental RFC, performance with misbehaving nodes and outside attackers is discussed in Sections 9.4, 9.5, and 9.6 of RFC4782 (Quick-Start).  This includes discussion of misbehaving senders and receivers; collusion between misbehaving routers; misbehaving middleboxes; and the potential use of Quick- Start to attack routers or to tie up available Quick-Start bandwidth. </ins> <del> The proposal should consider how the alternate congestion control mechanism would perform in the presence of transient events such as sudden congestion, a routing change, or a mobility event. Routing changes, link disconnections, intermittent link connectivity, and mobility are discussed in more detail in Section 17 of Tools. </del> <ins> 5.4. </ins> <del> As an example from an Experimental RFC, response to transient events is discussed in Section 9.2 of RFC4782 (Quick-Start). </del> <ins> When the proposal relies on explicit signals from the path, the effect of traffic passing through the tunnel - where routers may not be aware of the underlying flow - MUST be considered. </ins> <del> Incremental Deployment. </del> <ins> 5.5. </ins> <del> The proposal should discuss whether the alternate congestion control mechanism allows for incremental deployment in the targeted environment.  For a mechanism targeted for deployment in the current Internet, it would be helpful for the proposal to discuss what is known (if anything) about the correct operation of the mechanism with some of the equipment installed in the current Internet, e.g., routers, transparent proxies, WAN optimizers, intrusion detection systems, home routers, and the like. </del> <ins> RFC4653 discusses the effect of extreme packet reordering. </ins> <del> As a similar concern, if the alternate congestion control mechanism is intended only for specific environments (and not the global Internet), the proposal should consider how this intention is to be carried out.  The community will have to address the question of whether the scope can be enforced by simply stating the restrictions or whether additional protocol mechanisms are required to enforce the scoping.  The answer will necessarily depend on the change being proposed. </del> <ins> 5.6. </ins> <del> As an example from an Experimental RFC, deployment issues are discussed in Sections 10.3 and 10.4 of RFC4782 (Quick-Start). </del> <ins> The proposal should consider how the alternate congestion control mechanism would perform in the presence of transient events such as sudden congestion, a routing change, or a mobility event.  Routing changes, link disconnections, intermittent link connectivity, and mobility are discussed in more detail in Section 17 of Tools. </ins> <del> 4. </del> <ins> As an example from an Experimental RFC, response to transient events is discussed in Section 9.2 of RFC4782 (Quick-Start). </ins> <del> This section suggests minimum requirements for a document to be approved as Experimental with approval for widespread deployment in the global Internet. </del> <ins> 5.6.1. </ins> <del> The minimum requirements for approval for widespread deployment in the global Internet include the following guidelines on: (1) assessing the impact on standard congestion control, (2) performance in wireless environments, (4) investigation of the proposed mechanism in a range of environments, (5) protection against congestion collapse, and (12) discussing whether the mechanism allows for incremental deployment. </del> <ins> An IETF transport is not tied to a specific Internet path.  The set of routers forming a path can and do change with time, this will also cause the properties of the path to change with respect to time.  New CCs MUST evaluate the impact of changes in the path, and be robust to changes in path characteristics on the interval of common Internet re-routing intervals. </ins> <del> For other guidelines, 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. </del> <ins> Event when the routers constituting a path does not change, the properties of that path can vary, with similar impacts on congestion control 5.7. Multipath transport protocols permit more than one path to be differentiated and used by a single connection at the sender.  A multipath sender can schedule which packets travel on which of its active paths.  This enables a tradeoff in timeliness and reliability. One use is to provide fail-over from one path to another when the original path is no longer viable or to switch the traffic from one path to another when this is expected to improve performance (latency, throughput, reliability, cost).  Designs need to independently track the congestion state of each path, and need to demonstrate independent congestion control for each path being used. New multipath CCs that implement path fail-over MUST evaluate the harm resulting from a change in the path, and show that this does not result in flow starvation.  Synchronisation of failover (e.g., where multiple flows change their path on similar timeframes) can also contribute to harm and/or reduce fairness, these effects also ought to be evaluated. A concurrent multipath transport protocol simultaneously schedules flows to aggregate the capacity across multiple paths.  The Internet provides no guarantee that different paths (e.g., using different endpoint addresses) are disjoint.  This has additional implications: New CCs MUST evaluate the potential harm to other flows when the multiple paths share a common congested bottleneck (or share resources that are coupled between different paths, such as an overall capacity limit), and SHOULD consider the fairness with other flows.  Synchronisation of CC mechanisms (e.g., where multiple flows change their behaviour on similar timeframes) can also contribute to harm and/or reduce fairness, these effects also ought to be evaluated.  At the time of writing, there are no IETF standards for concurrent multipath congestion control in the general Internet. </ins> <del> 5. </del> <ins> 6. </ins> This document does not represent a change to any aspect of the TCP/IP protocol suite and therefore does not directly impact Internet