On Mon, Nov 9, 2020 at 10:31 AM 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. > > Lucas admitted that connection migration does not support the paths being used concurrently, possibly going over different networks. Behcet > > When I look at RFC 6824 it says: > > > > A Multipath TCP connection provides a bidirectional bytestream > > between two hosts communicating like normal TCP and, thus, does not > > require any change to the applications. However, Multipath TCP > > enables the hosts to use different paths with different IP addresses > > to exchange packets belonging to the MPTCP connection. A Multipath > > TCP connection appears like a normal TCP connection to an > > application. > > > 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. > > Olivier >
