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

[Scott Brim <[e-mail]>]

William Herrin allegedly wrote on 11/02/2009 4:28 PM:
> On Mon, Nov 2, 2009 at 1:47 PM,  <[e-mail]> wrote:
>> 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.

An e2e security mechanism / token that identifies the flow.  See the
security bullet.

But there are corner cases where it is extremely difficult to establish
a stable src/dst address pair.  In particular if BGP and NAT are set up
such that you contact me on one address, I reply on my other address ...
and you do the same on your end.  Since NAT is now architecture, it is
important that initial setup be as independent from addresses as
possible.  I believe we're essentially there but we have to prove it.

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

See previous paragraph.

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

My biggest con is if your destination is multiply connected behind two
non-synchronized intrusion prevention devices.

Scott