Original text:
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 <del> 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>  6.

Reviewer comments:
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 ]." 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.

Revised text:
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  <ins> overall capacity limit), and SHOULD consider the potential for harm to 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> 6.