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. Cheers, Lucas >
