Hi, Lucas, On Fri, Nov 6, 2020 at 11:17 AM Lucas Pardue <[email protected]> wrote:
> Hey Spencer, > > What I'm seeing (as an individual) is that the term multipath is too > nebulous. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > 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. > I think that last part is exactly right. Best, Spencer > 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 >> >
