On Mon, Nov 23, 2020 at 8:23 AM Spencer Dawkins at IETF < [email protected]> wrote:
> 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. > > My suggestion is (as suggested by someone already, maybe Jana, I think): go for a BOF. I think mpquic community is large enough, prepared enough, good enough to handle a very successful BOF in IETF 110 which is the next one. Can quickly form a WG and develop a beautiful mpquic or whatever we want to call it. Behcet > 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 >> >>
