Subject: Re: [multipathtcp] codepoint for mptcp options

From: [email-masked] (Noel Chiappa)
Date: Tue, 14 Feb 2012 11:52:28 -0500 (EST)

> From: "Eggert, Lars" <[email-masked]>

    > If you have a single-homed host talking to a multi-homed host, MPTCP
    > will be opening connections along multiple paths but only one IP
    > address is in use at one end. I don't think this case is described
    > by either "multi-address" or "multi-IP".
    > Also, the WG and protocol are also named "multipath" TCP. Using a
    > different name for the option is confusing (and renaming the
    > protocol and WG is impractical and confusing.)

I don't have any strong opinion on the name, and the latter point is a
good one.

However, on the purely technical level, I think Joe is sort of correct.  The
current TCP/IP architecture doesn't give users any control over paths (at
least, as routing would think of that term). Multiple addresses/interfaces are
a 'poor man's way' of providing a certain amount of path diversity, but it can
make no guarantee, because of the previous point.

Even with a single TCP connection between two singly-addressed hosts, packets
from the connection might flow over two paths (but usually don't, because ISPs
try to avoid that because it can cause packet reordering). And I can imagine
MPTCP connections where the packets on two sub-connections all take the exact
same path through the network (e.g. a multi-homed host with two interfaces to
the same network, for reliability reasons - although people have used ARP
hacks in the past for that particular capability).

Yes, multiple sub-connections to different addresses will usually get you
a different path - but there's no control, or guarantee.

	Noel

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 14 Feb 2012 17:21:23 +0000

> a different path - but there's no control, or guarantee.

Good point.

The original research work on MPTCP in the Trilogy project looked at cases where a multipath-aware routing layer exposed the presence of multiple paths explicitly, and the end systems could indicate which path a flow should take.

For the IETF standardization of MPTCP, that part got dropped, since the current Internet routing layer obviously doesn't support that. But the MPTCP design encompasses such cases.

Lars