(I said I would try to post a bunch in this thread. Apparently I'm failing)
On Fri, Nov 6, 2020 at 11:45 AM Mikkel Fahnøe Jørgensen <[email protected]> wrote: > 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. > I'm not sure what the protocol difference is between the two cases. I understand the difference between sending on one path and sending on another path, but once you've started sending on two (or more) paths, I'm not sure what the protocol requirement is to stop sending on one of them. I'm even more confused if we're talking about sending datagrams, rather than reliable streams. I understand why a scheduler might want to limit itself to sending on one path in normal operation, but I'm trying to understand a different point. Does my question make sense? Best, Spencer > 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 >> >
