Re: [multipathtcp] Multipath Address Family

[Michael Tüxen <[e-mail]>]

On Nov 23, 2009, at 10:40 PM, Pasi Sarolahti wrote:

> 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.
There is one thing that I do not understand. Currently there is no way a DNS
server resolves a name indicating that all addresses belong to the same host.
You just get a list of addresses. They might belong to one host or not.

At least for SCTP this is important and makes it impossible to use DNS to
resolve a name to multiple addresses belonging to the same host.

Best regards
Michael
> 
> 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
> 
> _______________________________________________
> multipathtcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>