Hi Behcet On Fri, Oct 23, 2020 at 4:15 PM Behcet Sarikaya <[email protected]> wrote:
> 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. > > As an individual. I'll repeat my comment, I've seen little evidence that some design that enables bandwidth aggregation in the QUIC transport over multiple paths offers advantages over a well-tuned QUIC stack that delivers over a single path. If the benefits of bandwidth are so huge, I might expect that people would be clambering to add this quickly with multiple QUIC connections coordinated in the application layer. That would allow deployment and testing without needing to wait for the transport to be redesigned. Let's not forget the disadvantages that bundling bandwidth can come with too. These could be perfunctory or monetary. Cheers Lucas
