Hey Olivier, On Mon, Nov 9, 2020 at 4:31 PM Olivier Bonaventure < [email protected]> wrote:
> Lucas, > > > > On Mon, Nov 9, 2020 at 3:55 PM Behcet Sarikaya <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hi Folks, > > I agree with Mikkel's points. > > To Lucas: I meant my short mail sometime ago I think it was before > > the interim (?) where I explained that connection migration is > > mobility support which should (from layering point of view) be in IP > > layer. In fact if IP layer has this support then then no need for > > connection migration in QUIC, so those procedures in the code do not > > get executed. > > > > Multipath is multiple interface support. It seems more and more like > > multipath probably better belongs in transport layer. Traffic in > > each interface may go over different networks (in my case on over T > > Mobile and the other AT&T). I believe a different PN is well > > justified in multipath as we have it in the base draft because of > > these traffic conditions (no offense to Christian). > > > > > > I still don't see why the current features of connection migration are > > not in some way a form of multipath. > > You are right, connection migration is the weakest form of multipath. > Thanks. We heard use cases that would like stronger forms. I think it will help continue to move the discussion forward if we can establish some common ground on terms and capabilities. This paragraph of RFC6824 then continues as follows : > > However, to the network layer, each MPTCP subflow looks > like a regular TCP flow whose segments carry a new TCP option type. > Multipath TCP manages the creation, removal, and utilization of these > subflows to send data. The number of subflows that are managed > within a Multipath TCP connection is not fixed and it can fluctuate > during the lifetime of the Multipath TCP connection. > > This is not really connection migration and MPTCP provides much more > multipath capabilities than connection migration. > Yeah I follow. As someone coming from QUIC, the first sentence is kind of easily negated (which is a benefit IIUC). I think the remainder of the paragraph is partially satisfied by QUIC v1 if we consider PATH_CHALLENGE/PATH_RESPONSE and NEW_CONNECTION_ID/RETIRE_CONNECTION_ID. But it starts to fall apart when you want to do more complicated things. I think understanding the gaps in the transport signalling would be useful to document in isolation to any specific solution. draft-deconinck-quic-multipath has done some of that work already but it gets a little too tied up with the solution IMO. Cheers Lucas
