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: Maybe I am overly sensitive, but this way of discussing the issue feels dated, from a time when transport and congestion control where specified jointly. I think that ceased to be the case many years ago, for example with implementations of TCP providing choices between multiple congestion algorithms. (Indeed, DCCP itself provides a choice between two algorithms.) The Bis draft should probably present the issue differently.
Speaking of fairness, I also wonder if there is an accurate definition for it. There has been activity on the topic at the IETF (on in academia) : URL URL URL should this be discussed in the draft ?
Discussed at IETF 117: Matt: Replace fairness with freedom from starvation. Fairness only makes sense at low bandwidth. Christian: Not focus entirely at fairness, non-starvation goal is good. Gorry: Suggestion to put it in other draft, but not in this one Overall, get rid of it all together for now
In academia a next metric is to look at harm rather than fairness: URL
That's a pretty good reference, Mirja!
The reality is that Cubic has a horrific effect on the Internet: it is pretty efficient at building queues and making life terrible for others. The classic example is the parent busy on a video conference from home, and then seeing the perceived quality go down sharply because the teenager started downloading a movie... Which means I would take "fairness with Cubic" with a huge grain of salt. As is, yes, let it run and get some bandwidth, but make sure that it gets seriously penalized, so there is an incentive to replace it by something better...
A more serious problem is harm to tiny transactions using any protocol. They have to rely on timeouts for loss recovery. I suggest replacing this with absolute upper bounds on loss rates. E..g. see: URL Likewise for excessive standing queues, and to a lessor extent excessive CE marks.
Modulo the comments I've already posted, LGTMThe last changes by NAME probably mitigate my issues. I think we will have to come back to definition of harm and to the "self compete" part, but this is good enough for the next iteration of the draft.