Re: [multipathtcp] API: which address to use

Hello Pasi,

I like the idea. 
But I have several questions. I think there might be an alternative: having 
SOCK_MULTISTREAM or using a combination socket type like SOCK_STREAM | SOCK_MULTIPATH 
from the following reasons.

 Strictly speaking, AF_MULTIPATH is not a new address type. 

 SCTP socket can be created with AF_INET or AF_INET6, but the socket can
 support multiple addresses. It's a bit orthgonal behavior from AF_MULTIPATH

 If the main point of having AF_MULTIPATH is to distinguish between the current 
 TCP socket and multipath TCP socket, using SOCK_MULTISTRAM is not a problem.

 we might support one-ended approach with the same API.

Also, in my feeling, we will need new bind(), connect() to specify multiple 
addresses. just like sctp_bindx(), sctp_connectx(). 

Thanks,
--
Yoshifumi Nishida
nishida@sfc.wide.ad.jp

From: Pasi Sarolahti <pasi.sarolahti@iki.fi>
Subject: Re: [multipathtcp] API: which address to use
Date: Tue, 10 Nov 2009 14:01:59 +0900
Message-ID: <E03D46E1-51EA-4273-A8A7-4F37F88B2E92@iki.fi>

 > On Nov 9, 2009, at 10:42 PM, William Herrin wrote:
 > 
 > > On Mon, Nov 9, 2009 at 5:49 AM, Pasi Sarolahti <pasi.sarolahti@iki.fi>
 > > wrote:
 > >> This problem was just discussed in the meeting. Could one possible
 > >> solution
 > >> to the getsockname semantics problem be to use a separate address
 > >> family for
 > >> multipath connections? It could be similarly structured to the
 > >> traditional
 > >> AF, but from the different AF the app would know the semantics are
 > >> different.
 > >
 > > Not really, no.
 > >
 > > Backwards compatibility is an issue, as you mentioned. So is a desire
 > > to be able to use both IPv4 and IPv6 paths in a single multipath TCP
 > > connection. If it's a legacy app then it's expecting getsockname to
 > > return the same address family that it used to initiate the socket. If
 > > you provide something else you could open a path for buffer overflows
 > > or other mischief.
 > 
 > Ok, so there could be a non-backwards compatible way and a
 > (pseudo)backwards compatible way. I don't think these had to be
 > exclusive, and both could be supported at the same time.
 > 
 > Non-backwards compatible version would be to use new AF_MULTIPATH,
 > that would be an array of AF_INET and AF_INET6 entries. Of course that
 > would need to be used consistently throughout the connection
 > lifetime. gethostname and getpeername would return the current set of
 > active addresses at local or remote end. bind() could use this to bind
 > to several addresses at a time. connect() could use this to give more
 > than one known destination addresses to connect to (although the MPTCP
 > protocol logic may prevent the actual connect operation from happening
 > simultaneously).  gethostbyname might return several addresses from
 > DNS in a single AF_MULTIPATH record, to be directly used by
 > connect(AF_MULTIPATH), instead of needing to cycle through the
 > addresses separately, as a traditional single-homed version would
 > do. This would require modifications also elsewhere than TCP code, but
 > that's what you get for having an API that exposes the IP address to
 > the application and assumes only one address is in use at a time.
 > 
 > The backwards compatible version could just return the oldest active
 > address and hope nothing breaks on legacy apps. I don't know if this
 > is better or worse choice than returning the first used address that
 > might not exist anymore. Has it been specified anywhere that
 > getsockname/getpeername should return same result through the
 > connection lifetime?
 > 
 > - Pasi
 > 
 > _______________________________________________
 > multipathtcp mailing list
 > multipathtcp@ietf.org
 > https://www.ietf.org/mailman/listinfo/multipathtcp