Code change:
It closes the issue by explicitly stating the I-D describes two use- cases: One we know more about, one much less. There is no intention to add a range of other use-cases in between. I hope this calls out some of the issues and that new proposers could understand where they ought to evaluate.
MP variants of TCP and QUIC, as well as SCTP may see some deployments - should this document mention something aroud coupled congestion control vs. single path congestion control also?
Yes. But we should note that it is still in research.
I have mixed feelings there. If users have payed for a wireless subscription and a land line subscription, why should they not use the full capacity of both paths? I see the "selfish" case for proper scheduling, such as not sending delay sensitive traffic on a lossy path. But I don't see anything with the same moral level as "don't cause congestion" or "don't cause buffer bloat".
Discussed at IETF 117: Christian: Not enough info to make a recommendation Gorry: We should think about it Ian: Inclination is that we don't have enough information to make a recommendation Matt: Impact is no worse than browsers using multiple connections
Gorry will take a look if he has anything constructive to write here; if so, we will run the text by the community. otherwise, close with no action.
See PR for some initial text.
I am really not sure that we should say much about multipath at all, besides the minimum -- making sure that any use of a path is not worse than creating a separate connection on that path. In PR , Gorry is trying to separate "multipath for failover" and "multipath for load balancing". But these are only two points in the spectrum of things that can be done. 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.

Related discussion:
text: 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.