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

[Martin Duke <[e-mail]>]

Hi Spencer,

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

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.

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