Re: [multipathtcp] Multipath Address Family

[Yoshifumi Nishida <[e-mail]>]

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