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

[Behcet Sarikaya <[e-mail]>]

Hi Christian,

What about MPTCP? It would be good to know what MPTCP does in this case?
Also does having a different packet number space create problems, or is it
just your personal preference?

Behcet

On Thu, Oct 1, 2020 at 2:58 AM Christian Huitema <[e-mail]>
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.
>>>
>>
>>
>>
>