RE: [Ipoverib] Comments on IPoIB Connected Mode Connection Establ ishment

[Dror Goldenberg <[e-mail]>]

> From: Vivek Kashyap [mailto:[e-mail]] 
> Sent: Thursday, August 18, 2005 9:36 AM
> 
> On Wed, 17 Aug 2005, Dror Goldenberg wrote:
> 
> >
> >
> >> From: Vivek Kashyap [mailto:[e-mail]]
> >> 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. 

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

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 ?

I think it'll be best if we can use the standard active-active mechanism. 
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>

_______________________________________________
IPoverIB mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipoverib