Hi Lucas, Olivier,
On Mon, Nov 9, 2020 at 10:51 AM Lucas Pardue <[email protected]> wrote: > 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. > > I don't think Olivier would wish to undermine the most important feature of multipath: multiple paths going over concurrently possible over different networks. Then he can not justify many features in draft-deconinck-quic-multipath. Behcet > Cheers > Lucas > >
