On Thu, Oct 1, 2020 at 10:28 AM Roberto Peon <[email protected]> wrote: > I’m probably on the other side of the coin here. > Were we doing MP, I’d prefer to have a separate packet-space per path, > because you probably need a separate congestion-controller instance per > path. >
me too. Behcet > -=R > > > > *From: *QUIC <[email protected]> on behalf of Behcet Sarikaya < > [email protected]> > *Reply-To: *"[email protected]" <[email protected]> > *Date: *Thursday, October 1, 2020 at 8:04 AM > *To: *Christian Huitema <[email protected]> > *Cc: *Matt Joras <[email protected]>, Olivier Bonaventure < > [email protected]>, Spencer Dawkins at IETF < > [email protected]>, Ian Swett <ianswett= > [email protected]>, QUIC WG <[email protected]>, Martin Duke < > [email protected]> > *Subject: *Re: Preparing for discussion on what to do about the multipath > extension milestone > > > > 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 <[email protected]> > 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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Ddeconinck-2Dmultipath-2Dquic&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=yV58k7v0W6KRG-4kJdhZ3Hs461h_EZKSw7VT6VHgsvU&s=qRLqBfssWffIVMcb3b7R5gxykJMN9tqDTp7pq9j5QCY&e=>), > 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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Ddeconinck-2Dmultipath-2Dquic&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=yV58k7v0W6KRG-4kJdhZ3Hs461h_EZKSw7VT6VHgsvU&s=qRLqBfssWffIVMcb3b7R5gxykJMN9tqDTp7pq9j5QCY&e=> > 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/ > <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbonaventure-2Dquic-2Datsss-2Doverview_&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=yV58k7v0W6KRG-4kJdhZ3Hs461h_EZKSw7VT6VHgsvU&s=79s85o1Msi5birIYHLoQ2DCLdCA8M8KOYgh_gWY81EI&e=> > . > > > > 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. > > > > > >
