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

[Martin Thomson <[e-mail]>]

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