RE: [rddp] Connection Startup
"Talpey, Thomas" <Thomas.Talpey@netapp.com> Sat, 04 October 2003 01:49 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07267 for <rddp-archive@odin.ietf.org>; Fri, 3 Oct 2003 21:49:23 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5bXa-0007KK-Ev for rddp-archive@odin.ietf.org; Fri, 03 Oct 2003 21:49:02 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h941n233028158 for rddp-archive@odin.ietf.org; Fri, 3 Oct 2003 21:49:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5bXa-0007K5-BC for rddp-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 21:49:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07240 for <rddp-web-archive@ietf.org>; Fri, 3 Oct 2003 21:48:52 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5bXX-0001pO-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 21:48:59 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5bXW-0001pL-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 21:48:58 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5bXZ-0007IT-4J; Fri, 03 Oct 2003 21:49:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5bWv-0007Hd-EQ for rddp@optimus.ietf.org; Fri, 03 Oct 2003 21:48:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07196 for <rddp@ietf.org>; Fri, 3 Oct 2003 21:48:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5bWs-0001od-00 for rddp@ietf.org; Fri, 03 Oct 2003 21:48:18 -0400
Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 1A5bWr-0001oA-00 for rddp@ietf.org; Fri, 03 Oct 2003 21:48:17 -0400
Received: from frejya.corp.netapp.com (frejya [10.10.20.91]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id h941lm4Z019647; Fri, 3 Oct 2003 18:47:48 -0700 (PDT)
Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.10.22.171]) by frejya.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id h941lmCV021966; Fri, 3 Oct 2003 18:47:48 -0700 (PDT)
Received: from tmt.netapp.com ([10.97.6.32]) by silver.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 3 Oct 2003 21:47:43 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38A19.806DC980"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
Subject: RE: [rddp] Connection Startup
Date: Fri, 03 Oct 2003 18:47:15 -0700
Message-ID: <5.2.1.1.2.20031003213259.01eba958@silver.nane.netapp.com>
Thread-Topic: [rddp] Connection Startup
Thread-Index: AcOKGYDQ3LVqL4YeRGatW55E5tHyAw==
From: "Talpey, Thomas" <Thomas.Talpey@netapp.com>
To: Jim Pinkerton <jpink@windows.microsoft.com>
Cc: rddp@ietf.org
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:rddp-request@ietf.org?subject=subscribe>
A draft is only a proposal :-) Seriously, I can see NFS/RDMA going either way, though you are correct the negotiation as proposed negotiates and does not, in fact, require private data. I do not believe NFS/RDMA is yet ready to say it never will. The DAFS protocol does use it. I believe the presence of optional private data is a good thing, will increase the applicability of DDP/RDMAP, and should be supported. I would like to see it supported when connecting over SCTP as well, in fact. Tom. At 09:25 PM 10/3/2003, Jim Pinkerton wrote: > >One technical clarification on a comment below. You state: > >> Both DAFS and NFS over iWarp match the private data >> approach. iSER is the only protocol proposed which negotiates in >> streaming mode and then shifts to RDMA mode. > >I'm still coming up to speed on the NFS proposal, but it looks like it >negotiates in streaming mode, and upgrades the connection into RDMA >Mode. See section 2.5.3 in >http://www.ietf.org/internet-drafts/draft-talpey-nfsv4-rdma-sess-00.txt. > >I know at least a one of the NFS over RDMA authors monitors this alias - >is the above statement correct? > > > >Jim > > > > >> -----Original Message----- >> From: Caitlin Bestler [mailto:cait@asomi.com] >> Sent: Thursday, October 02, 2003 7:59 AM >> To: Jim Pinkerton >> Cc: rddp@ietf.org; David Black >> Subject: Re: [rddp] Connection Startup >> >> >> On Wednesday, October 1, 2003, at 10:36 PM, Jim Pinkerton wrote: >> >> > >> > I don't see any real harm in an optional negotiation frame, since it >is >> > not required. But I think it is interesting to point out that the >> > example below makes it obvious that any content in the optional >> > negotiation frame is application specific (i.e. we are not >attempting >> > to >> > standardize (nor should we) what the contents of the start frame >are). >> > >> >> Yes, the intent is to carry opaque messages between the ULP peers >> to enable them to select/configure the RDMA endpoints compatibly. >> >> > For InfiniBand, there are a bunch of different definitions for the >> > private data contained in the connection setup sequence, and each >one >> > is >> > application dependent. There are a few parameters that are common, >but >> > the reality is little else is (see the InfiniBand spec Appendices at >> > http://infinibandta.org for the details). >> > >> > Thus to me the only rationale for creating the optional negotiation >> > frame is to enable a 3rd party to strip off the application data >from >> > the data stream, and present it through a separate interface to the >> > application. This is what Caitlin outlined below. From my jaded >view, >> > this is essentially "how do you graft software infrastructure that >was >> > created for InfiniBand on top of iWARP?". >> > >> >> If that were the goal, the "private data" would have included some of >> the standard fields for the CM protocol that are relevant -- >especially >> those related to RDMA Read credits. >> >> I believe a better statement of the goal is to encourage development >> of RDMA-aware transport neutral applications. For IETF purposes the >> critical transport neutrality is between SCTP and TCP. The next >> draft of the applicability statement will expand on this (it is >> under co-author review now, but if you read the latest SCTP and >> MPA drafts you'll see that transport neutral RDMA connection setup >> is easily achievable). Being compatible with the IT-API, >> the DAT APIs and the InfiniBand CM is just a bonus. >> >> There are indeed some applications that will be forced to deal with >> both the socket layer and the RDMA interface. But I believe this will >> be the exception. Both DAFS and NFS over iWarp match the private data >> approach. iSER is the only protocol proposed which negotiates in >> streaming mode and then shifts to RDMA mode. >> >> One of the main benefits of RDMA is that it allows the ULP to work >> at a much higher level of abstraction. A standard exchange of >> messages *before* RDMA endpoints are selected/configured that >> can be done *without* knowing which LLP is in use is totally >> consistent with that goal. >> >> It also *allows* the negotiation frame to be implemented by >> hardware/firmware/drivers and/or middle-ware. This is also >> a major benefit, because it *can* minimize context switching. >> >> > >> > >> > >> Caitlin Bestler - cait@asomi.com - http://asomi.com/ >> > > >_______________________________________________ >rddp mailing list >rddp@ietf.org >https://www1.ietf.org/mailman/listinfo/rddp
- RE: [rddp] Connection Startup Jim Pinkerton
- Re: [rddp] Connection Startup Caitlin Bestler
- RE: [rddp] Connection Startup Jim Pinkerton
- Re: [rddp] Connection Startup Caitlin Bestler
- RE: [rddp] Connection Startup Kanevsky, Arkady
- RE: [rddp] Connection Startup Jim Pinkerton
- RE: [rddp] Connection Startup Jim Pinkerton
- Re: [rddp] Connection Startup Caitlin Bestler
- RE: [rddp] Connection Startup Jim Pinkerton
- RE: [rddp] Connection Startup Jim Pinkerton
- RE: [rddp] Connection Startup Talpey, Thomas