Re: Preparing for discussion on what to do about the multipath extension milestone

[Ian Swett <[e-mail]>]

Given the responses, can we narrow down the way forward(ideally on a
different thread) to directions that are less open-ended?  I'll suggest
some options, but the chairs and/or ADs need to decide.
 1) No future work on multipath in the QUIC WG, in the belief the existing
connection migration functionality is sufficient.
 2) Adopt the existing draft as a starting point for QUIC multipath(
draft-deconinck-multipath-quic
<https://tools.ietf.org/html/draft-deconinck-multipath-quic>), with the
explicit goal of not expanding the scope of the document.
 3) Adopting multipath as a core QUIC WG deliverable.

I favor #2, but these may not be the right options.  Normally I'd say
people should work this out in person, but that doesn't seem viable at
the moment.  I'm happy to set up a long(3-4+hr) Google Meet to discuss this
via videoconference if that helps move the discussion forward.

Or we can form a design team, which typically takes O(3 months) to finish.

Ian

On Wed, Sep 30, 2020 at 3:15 PM Spencer Dawkins at IETF <
[e-mail]> wrote:

> Hi, Martin,
>
> Just a couple of thoughts here:
>
> On Wed, Sep 30, 2020 at 12:16 PM Martin Duke <[e-mail]>
> wrote:
>
>> (Speaking as an individual)
>>
>> There is some back-and-forth as to whether these are useful cases are
>> not. I'll take it on faith, given the proponents, that there is a real hope
>> of deploying this. However, I share the desire to not have the WG fully
>> consumed by MP-QUIC for the foreseeable future.
>>
>
> That sounds right. I'm assuming that getting the core QUIC specifications
> published and doing any cleanup work necessary SHOULD/MUST take priority,
> in the BCP 14 sense of those words.
>
> As Lars' initial note said, I'd also like to see the manageability,
> applicability, and datagram extension working group drafts, already adopted
> by QUIC, moving forward.
>
>
>> I don't think the community has well-established solutions for many
>> problems in this space (e.g. scheduling). However, I think QUIC is a far
>> better platform for experimentation than the alternatives, and would
>> support a draft similar to draft-deconinck-multipath-quic
>> <https://tools.ietf.org/html/draft-deconinck-multipath-quic> that
>> provided the required protocol extensions to make that happen [1].
>>
>
> I agree that scheduling is challenging - 3GPP is certainly spending time
> defining different strategies for behaviors, even in addition to the ones
> we described in
> https://datatracker.ietf.org/doc/draft-bonaventure-quic-atsss-overview/.
>
> And I agree that the QUIC protocol would be a better platform for
> experimentation than anything I can think of (other suggestions are, of
> course, welcome).
>
>
>> IIUC the hard, unsolved problems are common to all MP protocols, so I
>> don't think further research and future standards in this area are specific
>> to QUIC or appropriate for the QUIC Working Group. But experimental QUIC
>> extensions would accelerate this work, are appropriate for the WG, and may
>> get us to a place where we could confidently develop standards about it.
>>
>
> Targeting Experimental status for work in this area sounds like a fine
> plan to me (much better than not thinking about multicast in the IETF for a
> while longer).
>
> I know you have a variety of tools at your disposal to direct this work
> (MP-TCP was done in its own working group, for both Experimental and
> Standards-Track versions of the protocol specifications). Do the right
> thing, of course.
>
> What do you and Magnus need from members of the community, to help move
> forward on this?
>
> Best,
>
> Spencer
>
>
>> Martin Duke
>>
>> [1] I would prefer that this draft be Experimental, and have numerous
>> nits about the design that are not relevant to this thread.
>>
>
>
>