Original text:
differentiated and used by a single connection at the sender.  A multipath sender can schedule which packets travel on which of its active paths.  This enables a tradeoff in timeliness and reliability.  <del> One use is to provide fail-over from one path to another when the original path is no longer viable or to switch the traffic from one path to another when this is expected to improve performance </del>  (latency, throughput, reliability, cost).  Designs need to independently track the congestion state of each path, and need to demonstrate independent congestion control for each path being used.

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

Revised text:
differentiated and used by a single connection at the sender.  A multipath sender can schedule which packets travel on which of its active paths.  This enables a tradeoff in timeliness and reliability. <ins> There are various ways that multipath techniques can be used, </ins>  <ins> One example use is to provide fail-over from one path to another when the original path is no longer viable or to switch the traffic from one path to another when this is expected to improve performance </ins> (latency, throughput, reliability, cost).  Designs need to independently track the congestion state of each path, and need to demonstrate independent congestion control for each path being used.