Hi Lucas,
On Mon, Nov 9, 2020 at 10:12 AM Lucas Pardue <[email protected]> wrote: > Hi Behcet, > > On Mon, Nov 9, 2020 at 3:55 PM Behcet Sarikaya <[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. 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. > > > QUIC provides this, albeit restricting the paths from being used concurrently. > > This last sentence says it all. Also attention to the case I mentioned above where the client has some kind of mobility support and its IP address does not change (3GPP has that kind of support) but that does not invalidate the "need" for multipath, i.e. these two protocol mechanisms are orthogonal, you may need both, need one or none. Behcet > Cheers, > > Lucas > > >>
