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 > > <[email protected]> wrote: > >> Hi, Martin, > >> > >> Just a couple of thoughts here: > >> > >> On Wed, Sep 30, 2020 at 12:16 PM Martin Duke <[email protected]> > >> 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. > >> > >>
