No doubt there are some overlaps between multipath and migration, but I think it would help the discussion to make a clear distinction. Migration means traffic moves majorily on one path at a time, and multipath means that traffic predominantly moves on multipath paths at a time.
Where this is an overlap is where multipath predominantly sends on one channel but can with short notice choose to send on another or on several path based on prevailing conditions. This is broader than migration where path availability seems to be the primary selection criteria, whereas multipath may choose on latency, bandwidth etc. - of course migration can also do that to an extend, which is why it is not clear cut. Still migration does not allow for sustained concurrent traffic on multiple paths, while multipath does. Kind Regards, Mikkel Fahnøe Jørgensen On 6 November 2020 at 18.17.33, Lucas Pardue ([email protected]) wrote: Hey Spencer, What I'm seeing (as an individual) is that the term multipath is too nebulous. There's a spectrum of use cases that can benefit from the use of independent paths while using the same logical QUIC connection. On one end, multiple paths are used during the lifetime of a single QUIC connection. On the other end multipaths paths are kept alive (albeit maybe quiescent) for redundancy or bandwidth aggregation. If the connection migration feature can satisfy some part of the use case range, then I think it's fair to say that QUIC supports "multipath use cases", even if we don't explicitly say there is a multipath protocol feature. Maybe we didn't make this observation earlier but that doesn't change the fact that path independence and migration is in the DNA of QUIC. If folks want stuff on the other end of the spectrum, then it can help to map how the additional possible technological solutions satisfy the use cases. We should probably define some more precise terminology; getting clarity now will help avoid "no true Scotsman" scenarios if people start writing I-Ds and experimenting. This is especially important if any proposals end up substituting or supplanting the existing connection migration feature in the core QUIC. I think this aligns with some of your thinking Spencer. Others could disagree on some of my points. I just think there's a lot of shades of grey in this topic. Cheers Lucas On Fri, Nov 6, 2020 at 4:42 PM Spencer Dawkins at IETF <[email protected]> wrote: For what it's worth, On Fri, Nov 6, 2020 at 10:16 AM Lucas Pardue <[email protected]> wrote: Hi Behcet, There is no existing multipath mechanisms in QUICv1. Period. Please refer to my mail. That's a strong assertion. I'm not sure if members of the QUIC WG would agree. I don't know what email you are referring to, for the sake of discussion have you got a link or could you expand on why you think that QUIC v1 doesn't support multiple paths? I don't remember anyone characterizing connection migration as "support for multipath", before Jana's post on October 27, at https://mailarchive.ietf.org/arch/msg/quic/AhDWbrNYsdevwq9COGeGc2YK168/, but I could certainly have missed that - extracting from Jana's post: "We have multipath in QUIC. It may not be enough, but we agreed in this wg that this would be a good first cut to have. I believe this satisfies the charter text as we have it right now. We've just finished building the use of multipath in QUIC, and I'd like us to get some experience with it before considering how to expand its scope or how to improve it further." So, at least, I think that's what we're talking about - connection migration from one path to another, as a type of "support for multipath" in QUIC. From my to Jana in this thread: As an aside - I submitted a quick -00 draft from the Github repo at https://github.com/SpencerDawkins/draft-dawkins-quic-what-to-do-with-multipath on Monday (I-D cutoff), and posted a pointer on this mailing list, but I've continued typing, and the current version in the repo now says this in Section 2.2.4. One important output from the QUIC interim meeting was the recognition that some participants view "Traffic Switching" as something like "protection switching" from an active path to a standby path, that doesn't happen often, while other participants view QUIC connection migration as a way of responding frequently to changing path conditions. This will be an important part of the conversation about multipath QUIC. If a QUIC endpoint opens and validates two or more connections, no additional setup or signaling is required for a sender to switch paths - that can begin with the next packet queued for transmission. This would allow "Traffic Splitting" for unordered QUIC datagram packets [I-D.ietf-quic-datagram], with an upper-layer mechanism providing flow ordering if that is needed. That's an example of the kind of discussion I'm hoping that we continue to have. Best, Spencer
