Re: [multipathtcp] High-level design decisions /architecture

[William Herrin <[e-mail]>]

On Mon, Nov 2, 2009 at 1:47 PM,  <[e-mail]> wrote:

Hi Philip,

Apologies if any of this rehashes discussions you've already had.

> The MPTCP connection is identified, from an apps perspective, by the
> addresses associated with the original path (even if that subflow /path
> closes)

I'm concerned about this idea. One of the corner cases where shim6
falls apart is: once the connection migrates away from the original
addresses, how do the endpoints decide whether a new connection
request for the original addresses means the migrated addresses or the
current holder of the addresses? Think: FTP.


> A SYN/ACK exchange (on a single path) checks that both ends support MPTCP,
> with automatic fall-back to TCP if not

We have an awful lot of TCP options that are only valid in the
SYN-SYN/ACK exchange and only 40 bytes to put them all. What's wrong
with starting all TCP connections in non-MP mode and allowing the
connection's initiator to request MPTCP starting with any packet that
expects an ACK?


> each MPTCP subflow looks exactly like an ordinary, semantically independent
> TCP flow. MPTCP effectively runs on top. So re-transmission, FINs etc are
> independent on each subflow

I'm almost sold on the idea of subflows. Can you give me a run down on
the pros and cons, particularly the cons?

Thanks,
Bill Herrin


-- 
William D. Herrin ................ [e-mail]  [e-mail]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004