RE: [Ipoverib] Comments on IPoIB Connected Mode Connection Establ ishment
Vivek Kashyap <kashyapv@us.ibm.com> Tue, 06 September 2005 08:08 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECYV1-0001C9-Bx; Tue, 06 Sep 2005 04:08:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECYUy-0001Bx-FU for ipoverib@megatron.ietf.org; Tue, 06 Sep 2005 04:08:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11948 for <ipoverib@ietf.org>; Tue, 6 Sep 2005 04:08:04 -0400 (EDT)
Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECYXr-0005BT-35 for ipoverib@ietf.org; Tue, 06 Sep 2005 04:11:08 -0400
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j8687Rlu129192 for <ipoverib@ietf.org>; Tue, 6 Sep 2005 04:07:33 -0400
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8686DMQ292818 for <ipoverib@ietf.org>; Tue, 6 Sep 2005 02:07:27 -0600
Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j867mUvG011006 for <ipoverib@ietf.org>; Tue, 6 Sep 2005 01:48:31 -0600
Received: from sig-9-65-17-53.mts.ibm.com (sig-9-65-17-53.mts.ibm.com [9.65.17.53]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j867mTT3010951; Tue, 6 Sep 2005 01:48:30 -0600
Date: Tue, 06 Sep 2005 00:39:55 -0700
From: Vivek Kashyap <kashyapv@us.ibm.com>
X-X-Sender: kashyapv@localhost.localdomain
To: Dror Goldenberg <gdror@mellanox.co.il>
Subject: RE: [Ipoverib] Comments on IPoIB Connected Mode Connection Establ ishment
In-Reply-To: <506C3D7B14CDD411A52C00025558DED60893A24D@mtlex01.yok.mtl.com>
Message-ID: <Pine.LNX.4.62.0509060019130.4382@localhost.localdomain>
References: <506C3D7B14CDD411A52C00025558DED60893A24D@mtlex01.yok.mtl.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Cc: IPoverIB <ipoverib@ietf.org>
X-BeenThere: ipoverib@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP over InfiniBand WG Discussion List <ipoverib.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipoverib>, <mailto:ipoverib-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipoverib@ietf.org>
List-Help: <mailto:ipoverib-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipoverib>, <mailto:ipoverib-request@ietf.org?subject=subscribe>
Sender: ipoverib-bounces@ietf.org
Errors-To: ipoverib-bounces@ietf.org
On Sun, 21 Aug 2005, Dror Goldenberg wrote: > > >> From: Vivek Kashyap [mailto:kashyapv@us.ibm.com] >> Sent: Thursday, August 18, 2005 9:36 AM >> >> On Wed, 17 Aug 2005, Dror Goldenberg wrote: >> >>> >>> >>>> From: Vivek Kashyap [mailto:kashyapv@us.ibm.com] >>>> 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> > > _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib
- RE: [Ipoverib] Comments on IPoIB Connected Mode C… Dror Goldenberg
- RE: [Ipoverib] Comments on IPoIB Connected Mode C… Vivek Kashyap
- Re: [Ipoverib] Comments on IPoIB Connected Mode C… Vivek Kashyap
- RE: [Ipoverib] Comments on IPoIB Connected Mode C… Dror Goldenberg
- RE: [Ipoverib] Comments on IPoIB Connected Mode C… Vivek Kashyap
- RE: [Ipoverib] Comments on IPoIB Connected Mode C… Dror Goldenberg
- RE: [Ipoverib] Comments on IPoIB Connected Mode C… Michael Krause
- RE: [Ipoverib] Comments on IPoIB Connected Mode C… Vivek Kashyap