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

[Spencer Dawkins at IETF <[e-mail]>]

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.
>