Code change:
contribute to harm and/or reduce fairness, these effects also ought to be evaluated. <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> Another example use is concurrent multipath, where the 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> 6.

Related discussion:
text: For example, in various QUIC implementations, I have also seen: multipath of ACK -- using the lowest latency path to carry ACKs for the other paths, multipath of loss recovery -- resending the content of packets lost on path A on the hopefully more reliable path B, multipath redundancy -- sending duplicate traffic on path A and B, so the receiver can pick whichever arrives first, multipath redundancy with FEC -- same as above, but send FEC redundancy instead of merely duplicating traffic, multipath affinity -- subsets of application traffic are tied to a specific path as long as that path is available. Not all of these have obvious congestion control consequences, but some do. For example: Multipath of ACK is widely implemented, and the draft multipath specifically supports it. It is particularly useful when one of the links is high bandwidth and high latency. But then, this means the multipath connection will enjoy a shorter RTT than the other connections sharing the same bottleneck, which generally results in a larger share of the capacity. Multipath redundancy was pioneered by the QUIC team at Ali-Baba, as a way to get lower latency when sending video streams. They do that when one of the paths is considered a bit suspect. Of course, it leads to using more bandwidth.
This was intentional - Failover has been om the RFC series for sometime, and has been deployed. Concurrent multipath is something that has been on the edge for quite a while, but was at the other extreme - in the middle there are many things ... If you have an exhaustive list of the CC-related ones, that could perhaps be useful, I was avoiding making that list. I note FEC has interesting interactions with CC.
I wouldn't mind text that made it clear that "concurrent multipath" is a continuum of immature ideas. But Gorry is right that failover is well established and everything else involves hand-waving.
Regarding FEC and CC, it depends whether FEC is below CC or above it. With TCP, it has to be below, but with QUIC it is typically above, with FEC frames being controlled by CC like datagram or Stream data frames. I missed one interesting data point in the previous list, interactions between loss recovery and multipath scheduling.
Discussed at IETF 118: Asking for folks to take a look and comment here
Looks good.