Hey Hannu, Spencer,
On Mon, Nov 23, 2020 at 2:23 PM 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. > Speaking as an individual, I think experimental work towards proving or disproving whether a single multipath QUIC design, within the set constraints, can solve several multipath use cases is valuable. Cheers Lucas
