Re: [multipathtcp] Multipath Address Family

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

On Nov 25, 2009, at 8:15 PM, Yoshifumi Nishida wrote:

> 
> Hello Michael, 
> 
> From: Michael Tüxen <[e-mail]>
> Subject: Re: [multipathtcp] Multipath Address Family
> Date: Wed, 25 Nov 2009 19:20:56 +0100
> Message-ID: <[e-mail]>
> 
>>>> just one note:
>>>> In SCTP we use sctp_connectx() to connect to multiple addresses.
>>>> Kacheong pointed a couple of years ago out that a more generic
>>>> connectx() would make sense to other protocols supporting multihoming
>>>> as well (but there were no).
>>> 
>>> Just curiosity, do you know the reason why generic connectx() doesn't exist? 
>>> it make sense to me since the call looks independent from sctp.
>> Because we were not sure what the right semantic would be:
>> 1. For SCTP (or other protocols supporting multihoming), we wanted something
>>   like "establish a transport connection with the peer having *all* given addresses.
>> 2. For TCP (or other protocols not supporting multihoming), we though something
>>   like "establish a transport connection with a peer having *one* of the given addresses.
>> This is very different. We also assume that if the user provides multiple address,
>> all the addresses belong the the *same* host. This makes it impossible to use
>> DNS for getting them...
> 
> Thanks for the clarification. But, I still have a question... Do we have to
> connect all given addresses?
You do not have to do anything right now, since it is not defined yet.
The situation for us was the following:
We know the peer has addr1, ... , addrn and we want to establish an SCTP association.
We do not want to test addr1 first, wait until the setup fails and then test addr2,
and so on. We want to setup an association in a fast way not being delayed because
addr1 currently fails. We have not specified if you send INITs to all addresses
simultaneously or send the first INIT to addr1 and the retransmission to addr2, or
in an other way. That is implementation specific. But do no want to wait for the
association setup to addr1 to fail (after several retransmissions) before trying
alternate addresses.
We can not do this with the existing system calls and introduced therefore the
sctp_connectx() system call. 
> If connectx() sends multiple SYNs simultaneously to the multiple destinations,
> it will be problematic. But, if connectx() has the following logic,
>  it tries to send a SYN one-by-one to each destination
>  it gets SYN-ACK, it stops to send a SYN and return.
But then it can take long until you setup you transport connection.
The application could just run a loop over the peer addresses and call connect()
to it, see if it works. If it fails try the next. This might take a long time
you you have a lot of addresses to try and some of them are not working.
> I don't see a big issue in the logic. It may be slow in some cases, though. 
> I mean, connectx() is used only to find one primary destination. Other destinations
> will be found during negotiations in the transport protocol. Not from connectx().
> --
> Yoshifumi Nishida
> [e-mail]
>