Re: [multipathtcp] Multipath Address Family

[Yoshifumi Nishida <[e-mail]>]

Hello Pasi,

Thanks for your response. 

From: Pasi Sarolahti <[e-mail]>
Subject: Multipath Address Family
Date: Mon, 23 Nov 2009 13:40:02 -0800
Message-ID: <[e-mail]>

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

I would say that the socket type indicates the semantics of communication. 
(as 'man socket' says.)  If communication style has been changed, we might need 
new one. If the transport service is completely the same from the API's point 
of view even if multipath is used or not, I think you're right. 
But, if you want to add extentions to streaming service, it can be a different 
communication semantic.

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

Yep, if SCTP supports this kind of AF, things might be easier..
Actually, in WIDE project, we tried to propose new AF called AF_BUNDLE for sctp, 
which has very similar concept of AF_MULTIPATH. An experimental code existed, 
but somehow it was not integrated into KAME's code... 

Anyway, we already have a standardized multipath stream protocol. 
it would not be very perferable if the API for two multipath stream 
protocols are very different. 
I'm not sure how this is important yet, but that's one point I care.

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

Yes. it's possible. but, I'm not very sure if it's intuitive...

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

Hmm, in your proposal, it seems to me that you want to update the 
return value for bind() and connect(), which might break the syntax of these calls.
If we want to keep the same syntax as the current one, we will need to have a 
new function that will get true return code for these functions. 
But, in my feeling, this might be almost the same as creating new bind() and connect().

Thanks,
--
Yoshifumi Nishida
[e-mail]