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.
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
