Hi Lucas,
On Fri, Oct 23, 2020 at 4:28 AM Lucas Pardue <[email protected]> wrote: > 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. > > Coming from IP layer, I have a message to QUIC enthusiasts: Connection migration is a solution for mobility at transport layer. Ideally, it should be IP layer. If a node moves, its connections normally break. So connection migration of QUIC solves that issue at the transport layer. OTOH multipath QUIC is a solution for multiple interfaces. If a node can be connected to the Internet over more than one interface using them simultaneously provides several advantages like increasing bandwidth, etc. Behcet > 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 > > > > >>
