Posting as an individual. Thanks to the time that people took to prepare, present and discuss, I gained a better understanding of this area.
One main takeaway for me is that thinking of QUIC v1 as singlepath puts it in an unfair box. Others, such as Jana, articulated this point better than I. QUIC is path independent, path aware and provides mechanisms, written in the core document, for endpoints to interact and interoperate about path-related things. Through the course of specification development things might have gone different, and we might be having a conversion now about whether the group should adopt a document that describes for instance just connection migration. But migration is in the core and, based on the Slack discussion following the interim, there appear to be several parties that have expressed an interest in testing deployments of Connection migration. This can be seen as some form of success. The use cases indicate that things like active-active paths or bandwidth aggregation are desirable. But I was unable to discern objectively how more of an optimal experience they would provide over a well tuned QUIC v1 endpoint that use connection migration. I encourage people to think about the charter goals for the QUIC protocol, what success looks like, and whether they think connection migration delivers a sufficiently good part of the multipath feature set that was vaguely described when we started off. Cheers Lucas >
