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
