RE: Comments on IPoIB Connected Mode Connection Establ ishment

On Sun, 21 Aug 2005, Dror Goldenberg wrote:

>
>
>> From: Vivek Kashyap [mailto:[email protected]]
>> Sent: Thursday, August 18, 2005 9:36 AM
>>
>> On Wed, 17 Aug 2005, Dror Goldenberg wrote:
>>
>>>
>>>
>>>> From: Vivek Kashyap [mailto:[email protected]]
>>>> Sent: Monday, August 15, 2005 9:41 AM
>>>>
>>>> On Wed, 10 Aug 2005, Dror Goldenberg wrote:
>
> <snip>
>
>>
>>>>> (2) Active/Active Model Support
>>>>>
>
>
> <snip>
>
>>>> 3. In case of the active-active connection the request from the
>>>> numerically smaller MAC Address (QPN+GID or probably just
>> the GID) is
>>>> terminated. The error code 'state connection' is a
>> possibility here.
>>>>
>>>> The active-active situation is known when it is determined
>> that there
>>>> is an outstanding request to the remote peer (as determined by
>>>> GID+QPN) while a request from the same is received on local
>>>> GID+ServiceID.
>>>
>>> In IB, active-active is only determined by equal Service IDs. See IB
>>> spec 1.2 vol1 12.9.7.1, the Active CM state machine goes to
>>> Peer-Compare state based solely on the Service ID.
>>> Therefore, if you want to have active-active, then you must
>> ensure that
>>> both service IDs are identical. In the current draft, the
>> Service IDs are
>>> different, as they include a remote QP number.
>>>
>>
>> Yes, if we are determining it based on the CM. However, I was
>> suggesting
>> the above as what the ipoib component will do when it is informed by
>> CM. It can return a suitable error to CM when it determines
>> that a particular
>> connection shouldn't be allowed. Is that not possible?
>>
>
> That wouldn't be "active/active" per se. But maybe it's just as good,
> because
> it just pushes this model to the ipoib layer. In a case of crossing
> connection
> requests one side is supposed to accept, while the other is supposed to
> reject. The rules for rejection have to be described in the RFC. Maybe it
> worth describing the state machine that now needs to be implemented
> in ipoib.

yes, need to look into it in detail. My initial thought is that the 
method of determining if there are connections in flight is based on
receiving a request source GID+QPN  while attempting a connection to the same.

>
> BTW, what will be the rejection reason ? Seems like the most appropriate is
> 28 - consumer reject.

seems ok to me.

>
> Note that it becomes tricky if you want to allow more than one
> connection on the same service ID. So, is there a way you can tell whether
> your peer is trying to establish the 1st or 2nd connection while you are
> trying to set up the 1st one ?

hmm...good point, unless we take it that any request that crosses is deemed
active-active. Once a connection is established further requests can
be made on the same Service-ID (or denied depending on the implementation).
>
> I think it'll be best if we can use the standard active-active mechanism.

We need a common Service-ID for it that must be known/derivable by both
the peers. Since masks are not supported by CMs using both QPNs in the 
service-ID is difficult.


> However, if we don't manage to find how, then this approach (rejection
> at the app level) will do the work. However, it will complicate the
> ipoib implementation and will duplicate the active-active work that
> is already implemented in the cm.
>
> -Dror
>
> <snip>
>
>