[multipathtcp] Multipath Address Family

[Pasi Sarolahti <[e-mail]>]

Hi,

(changed the topic line, it was earlier "API: which address to use".  
I'm responding to Yoshifumi below, but first wanted to post a general  
note.)

I wrote down some further thinking about the idea of multipath address  
family in the form of Internet-Draft, which I thought to be better  
than a long Email to the list. The draft is available at http://tools.ietf.org/html/draft-sarolahti-mptcp-af-multipath-00 
  and I'd be happy to hear further comments about it.

I think a new address family would be a minimal needed change to the  
current socket API, without extending the API with new operations, but  
yet provide an interface to handle multiple addresses in a socket. One  
potentially useful characteristic would be that this would allow name  
resolver to return multiple IPv4 and/or IPv6 addresses from the name  
server as a single sockaddr structure, that could be directly given as  
a parameter to a connect call, which would lead to trying which of the  
addresses are reachable for the MPTCP session. Traditionally this has  
been done in the applications, by cycling through the returned  
addresses from resolver one by one, until connect is successful.  
Especially dual-stack IPv6/IPv4 hosts should find such feature useful.

Yoshifumi- thanks for your comments! Some responses inline below.

On Nov 22, 2009, at 4:22 PM, Yoshifumi Nishida wrote:

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

I have thought the 'type' parameter in the socket call to specify the  
semantics of the socket functions such as read and write. To my  
understanding the purpose of the MPTCP exercise is to maintain similar  
read/write semantics to TCP, so if successful in this goal, the socket  
behavior should be equal to SOCK_STREAM. Or to put it differently,  
MPTCP is not a new protocol, it is just a (fairly large) modification  
to TCP.

> Strictly speaking, AF_MULTIPATH is not a new address type.

I see it as a kind of a super - address family: union of existing  
address families. But I think that would still fit under a definition  
of "address family". I understand that there might be different  
interpretations of what "address family" means, but if there is one  
specified & correct definition, I'd like to learn about it.

> 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

Yes, earlier protocols have done something different for their API.  
But I'd be interested to learn if there is something why the earlier  
protocols couldn't begin using something like multipath address family.

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

In my opinion, the main purpose is to be able to present multiple  
addresses associated with the same TCP socket. But different address  
family could be used to distinguish between multi- and singlehomed  
operations, too.

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

Yep, and that should be possible with AF_MULTIPATH, by having just one  
address in the address list. I think there might be cases where even  
single-homed TCP connections might benefit from multiaddress API, even  
if they ended up using just one of the given addresses at both ends  
(referring to the name resolver example above).

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

I think that adding completely new operations to the good old socket  
API might be problematic, and would lead to a more updating /  
maintenance burden in different systems and applications than a new  
address family would do. But I might be missing something in the  
required complexity of adding a new address family.

- Pasi