There seems to be three different approaches for multipath support, if I am not missing any:
https://datatracker.ietf.org/doc/draft-deconinck-quic-multipath/ https://datatracker.ietf.org/doc/draft-an-multipath-quic/ https://datatracker.ietf.org/doc/draft-huitema-quic-mpath-option/ Each of them addressing different use cases. It is not obvious to me that the experimentation would lead into single design rather than debate between the approaches. I would expect as the outcome of the experimentations deeper differences between the multipath mechanisms tailored for respective use cases. How can we draw any generic conclusions from such results? How would you compare the outcomes? Best regards Hannu -----Original Message----- From: QUIC <[email protected]> On Behalf Of Lars Eggert Sent: Friday, November 20, 2020 11:30 AM To: QUIC WG <[email protected]> Subject: Next steps for Multipath QUIC Hi, Lucas and me got asked what we'd see as the next steps for multipath support for QUIC. Here's our current thinking: The QUIC WG remains the default venue for continued open discussion of multipath experiments and results. The goal for this discussion is to help steer towards identifying whether a multipath design can emerge that (1) addresses a number of the use cases discussed during the interim, or new use cases that are similarly motivated (2) sees implementation and experimentation/deployment interest from a number of production stacks (3) is (as much as possible) a minimally-scoped extension to QUIC v1 that cleanly integrates with its concepts and other adopted extensions Until this has happened, we think it'd be premature to adopt one of the individual multipath designs that have been proposed as a WG work item. We hope this provides some clarification. Thanks, Lars and Lucas
