Hannu, On Mon, Nov 23, 2020 at 3:02 AM Flinck, Hannu (Nokia - FI/Espoo) < [email protected]> wrote:
> There seems to be three different approaches for multipath support, if I > am not missing any: > > https://datatracker.ietf.org/doc/draft-deconinck-quic-multipath/ > https://datatracker.ietf.org/doc/draft-an-multipath-quic/ > https://datatracker.ietf.org/doc/draft-huitema-quic-mpath-option/ > > Each of them addressing different use cases. It is not obvious to me that > the experimentation would lead into single design rather than debate > between the approaches. > I would expect as the outcome of the experimentations deeper differences > between the multipath mechanisms tailored for respective use cases. How can > we draw any generic conclusions from such results? How would you compare > the outcomes? > I agree with you on your question. I'm working to catalog the various strategies we've talked about in QUIC, in https://tools.ietf.org/html/draft-dawkins-quic-what-to-do-with-multipath-02#section-2.3 . Speaking only for myself, I don't anticipate one approach satisfying all of the use cases, which I'm thinking of in two categories: - The sender needs to control what to send next, and on what path, based on more knowledge of the paths and the application than a general-purpose transport scheduler can know, or - The sender is willing to delegate those decisions to a general-purpose transport scheduler, because that will be "good enough". Of course, I could be wrong about that. I look forward to hearing more about the experiments as we proceed. Best, Spencer > Best regards > Hannu > > > -----Original Message----- > From: QUIC <[email protected]> On Behalf Of Lars Eggert > Sent: Friday, November 20, 2020 11:30 AM > To: QUIC WG <[email protected]> > Subject: Next steps for Multipath QUIC > > Hi, > > Lucas and me got asked what we'd see as the next steps for multipath > support for QUIC. Here's our current thinking: > > The QUIC WG remains the default venue for continued open discussion of > multipath experiments and results. The goal for this discussion is to help > steer towards identifying whether a multipath design can emerge that > > (1) addresses a number of the use cases discussed during the interim, or > new use cases that are similarly motivated > > (2) sees implementation and experimentation/deployment interest from a > number of production stacks > > (3) is (as much as possible) a minimally-scoped extension to QUIC v1 that > cleanly integrates with its concepts and other adopted extensions > > Until this has happened, we think it'd be premature to adopt one of the > individual multipath designs that have been proposed as a WG work item. > > We hope this provides some clarification. > > Thanks, > Lars and Lucas > >
