Code change:
3.1.4. <del> When multiple competing flows all using the same alternate congestion </del> <ins> When multiple competing flows all use the same alternate congestion </ins> control algorithm, the proposal should explore how the capacity is <del> shared among the competing flows. </del> <ins> shared among the competing flows.  Capacity fairness can be important when a small number of similar flows compete to fill a bottleneck. It can however also not be useful: for example when comparing flows seek to send at different rates or when some of the flows do not last sufficiently long to approach asymptotic behavior. </ins> 3.1.5. <ins> In contexts where differing congestion control algorithms are used, it is important to understand whether an alternate congestion control algorithm can induce more harm to sharing flows than existing defined methods.  The measure of harm is not restricted to the equality of capacity, but ought also to consider metrics such as the latency introduced, or an increase in packet loss.  This evaluation must assess the potential to cause starvation, including assurance that a loss of all feedback (e.g., detected by expiry of a retransmission time out) results in backoff. 3.1.6. </ins> (TODO: Discuss short and long flows) 3.2.

Related discussion:
text: Starting to unpick where equal access is important and where harm for others becomes important. If merged, this
Issue possibly related to , but more focussed on refocus away from a fairness evaluation. When a transport uses a path to send packets (i.e. a flow), this can impact other Internet flows (possibly from or to other endpoints) that share the capacity of any common network device or link (i.e., are multiplexed) along the path. In turn, this can result in variation in capacity, loss, or additional latency. Transports and network layer scheduling can be designed to offer fairness between sharing flows. This comes with both strengths and weaknesses - it can reduce collateral damage to other flows; but it also can motivate the use of additional flows to gain additional network resource. Transport proposals need to be evaluate and avoid inducing flow starvation to the other flows that share resources along the path they use. Transports proposals need to be evaluate and ensure they treat a loss of all feedback (e.g., expiry of a retransmission time out) as an indication of persistent congestion.
Gorry will start with a PR that defines the terms; then we can talk about what to emphasize.
Also is related
One of the guidelines is "Fairness within the Alternate Congestion Control Algorithm". This a great consideration, but behind that are quite a few problems. The classic fairness evaluation derives from the equation about asymptotic behavior drawn by Matt Mathis, which end up requiring a non linear response to the frequency of a control signal such as packet loss or ECN marks. There are of course two problems. First, time scale, because many connections don't last long enough to approach asymptotic behavior. Second, scaling, as discussed for example in RFC3649. If an algorithm requires ever increasing spacing between control events to sustain larger data rates, then the control loop becomes very long, or, in the case of packet losses very noisy as "true" control events get intermixed with random losses. In contrast, algorithms with linear response scale very well, but do not naturally provide fairness. Which is kind of a bummer, and also a research topic. I think the Bis draft will have to recognize that tension somehow, and encourage experimentation.
The Guidelines section asks developers of new congestion control algorithms to discuss the "Impact on Standard TCP, SCTP ], and DCCP ]."