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

[Yoshifumi Nishida <[e-mail]>]

From: William Herrin <[e-mail]>
Subject: Re: [multipathtcp] High-level design decisions /architecture
Date: Mon, 2 Nov 2009 19:38:46 -0400
Message-ID: <[e-mail]>

 > On Mon, Nov 2, 2009 at 6:45 PM, marcelo bagnulo braun
 > <[e-mail]> wrote:
 > >> 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.
 > >>
 > >
 > > could you expand on this?
 > > I wasn't aware shim6 falls apart in any case neither this particular
 > > approach...
 > 
 > Hi Marcelo,
 > 
 > Consider the following scenario:
 > 
 > Host A comes online with 1.2.3.4.
 > Host A requests a new TCP connection to 5.6.7.8.
 > Established with host B at 5.6.7.8.
 > Host B adds 8.7.6.5
 > Host B removes 5.6.7.8
 > Host C comes online with 5.6.7.8.
 > Host A requests a new TCP connection to 5.6.7.8.
 > 
 > Which host does A connect to?
 > 
 > If the answer is C, protocols like FTP which initiate multiple TCP
 > connections to the same IP address fail once an endpoint gives up its
 > original address. That'll also impact web browsers which employ dns
 > pinning.

In case of ftp, the choice would be something like this?

 1: we don't support this case. ftp will fail.
 2: ftp client/server performs getsockname() before port/pasv to check its own active IP address.
    (But, we need to define getsockname() should return active IP address instead 
     of original IP)
 3: Develop new ftp for MPTCP (using new API etc..)

I personally prefer 1.. then might do 3 later..
In case of dns pinning, I don't see any issues.

Thanks,
--
Yoshifumi Nishida
[e-mail]