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

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

Hi, Martin,

On Thu, Oct 1, 2020 at 11:36 AM Martin Duke <[e-mail]> wrote:

> Hi Spencer,
>
> This is Magnus's charter so I don't want to be expansive in my comments as
> AD.
>

Sure. I wasn't sure whether you two had time to talk.

Part of my original question was whether you two thought this was QUIC work
or something else that might be chartered outside QUIC - I'm sorry if that
wasn't clear.


> I think the next step would be for the WG to come to consensus on
> this work, whatever that happens to be. My gentle suggestion is that a
> standards-track design for simultaneous flow on multiple paths is
> premature, and probably not QUIC-specfiic. However, a short experimental
> draft to enable this in QUIC would allow the research community to make
> progress faster.
>

Thank you for making that clearer (at least to me), and I agree completely
with that.

Best,

Spencer


> On Thu, Oct 1, 2020 at 7:40 AM Spencer Dawkins at IETF <
> [e-mail]> wrote:
>
>> Hi, Martin,
>>
>> On Thu, Oct 1, 2020 at 9:21 AM Martin Duke <[e-mail]>
>> wrote:
>>
>>> The concerns that Christian and MT raise are the same ones I was
>>> alluding to, but I do think a draft like this one that adds the necessary
>>> bits of protocol to enable multipath experimentation is the right scope. I
>>> don't feel strongly whether we should adopt this and fix it, or fix it and
>>> then adopt it.
>>>
>>
>> I had asked you and Magnus yesterday what our next steps on multicast
>> should be.
>>
>> Am I reading this correctly as "start working on this draft, on the QUIC
>> mailing list, and let the working group do the right thing"?
>>
>> I'd be fine with that, but wanted to check.
>>
>> Best,
>>
>> Spencer
>>
>>
>>> Martin
>>>
>>> On Thu, Oct 1, 2020 at 1:23 AM Martin Thomson <[e-mail]> wrote:
>>>
>>>> I share Christian's concerns about the draft, but it's not just ACKs,
>>>> it's the entire Uniflow concept that I would call into question.
>>>>
>>>> On Thu, Oct 1, 2020, at 17:25, Christian Huitema wrote:
>>>> > I am not sure that the current "mpquic" draft is the right approach.
>>>> > Specifically, I do not agree that having one packet number space per
>>>> > path is the right approach. This contradicts the design of QUIC V1,
>>>> in
>>>> > which data sent on multiple paths shares a common packet number
>>>> space.
>>>> > For example, in QUIC V1, we can start a connection on one path,
>>>> migrate
>>>> > to another path, and keep the same packet number space throughout. I
>>>> > find that a very nice property -- and also an essential property if
>>>> we
>>>> > want to support NAT rebinding. Handling multipath with a single
>>>> number
>>>> > space requires some book-keeping on the sender side to match
>>>> > acknowledgements and sending paths, but we have working code for that.
>>>> >
>>>> > I am also not convinced that we properly understand the concept of
>>>> > "path". There is very little in the QUIC V1 protocol that requires
>>>> > transmission paths to be symmetric: any packet sent from a node to a
>>>> > valid address of the peer will be accepted, provided the crypto
>>>> works.
>>>> > The linkage such requirement comes from the statement that a server
>>>> > starts directing traffic to a validated path when it sees the client
>>>> > using the same pair of addresses. This is an "implicit" linkage; I
>>>> > would expect that the first role of a multipoint extension would be
>>>> to
>>>> > replace that by an "explicit" statement of preferences.
>>>> >
>>>> > I am worried that we have a set of unresolved security issues around
>>>> > paths, largely linked to the requirement to support NAT rebinding. If
>>>> > we support NAT, the IP headers must be outside the authentication
>>>> > envelope of the crypto. There are plausible attacks in which the
>>>> > attacker splices a cryptographically valid packet and a forged IP
>>>> > header. We have some defensive heuristics, but if we study multipath
>>>> I
>>>> > hope we will end up with something better.
>>>> >
>>>> > -- Christian Huitema
>>>> >
>>>> > On 9/30/2020 5:51 PM, Ian Swett wrote:
>>>> > > 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.
>>>> > >>
>>>> > >>
>>>>
>>>>