From exim@www1.ietf.org Wed Oct 1 23:37:29 2003 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 XAA17058 for ; Wed, 1 Oct 2003 23:37:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4uH2-00085a-N5 for rddp-archive@odin.ietf.org; Wed, 01 Oct 2003 23:37:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h923b4Wk031093 for rddp-archive@odin.ietf.org; Wed, 1 Oct 2003 23:37:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4uH1-00085I-UV for rddp-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 23:37:03 -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 XAA17055 for ; Wed, 1 Oct 2003 23:36:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4uGz-0001hZ-00 for rddp-web-archive@ietf.org; Wed, 01 Oct 2003 23:37:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4uGz-0001hV-00 for rddp-web-archive@ietf.org; Wed, 01 Oct 2003 23:37:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4uGz-000844-J1; Wed, 01 Oct 2003 23:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4uGq-00083f-NX for rddp@optimus.ietf.org; Wed, 01 Oct 2003 23:36:52 -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 XAA17047 for ; Wed, 1 Oct 2003 23:36:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4uGo-0001hN-00 for rddp@ietf.org; Wed, 01 Oct 2003 23:36:50 -0400 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1A4uGn-0001hG-00 for rddp@ietf.org; Wed, 01 Oct 2003 23:36:50 -0400 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Oct 2003 20:36:20 -0700 Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 01 Oct 2003 20:36:19 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Oct 2003 20:36:15 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Wed, 1 Oct 2003 20:36:19 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 1 Oct 2003 20:36:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] Connection Startup Date: Wed, 1 Oct 2003 20:36:18 -0700 Message-ID: Thread-Topic: [rddp] Connection Startup thread-index: AcOHmRBeivlqq3SYRbyDsYkBcOs6xwA+WMfw From: "Jim Pinkerton" To: "Caitlin Bestler" , Cc: "David Black" X-OriginalArrivalTime: 02 Oct 2003 03:36:18.0637 (UTC) FILETIME=[573997D0:01C38896] Content-Transfer-Encoding: quoted-printable 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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). 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?".=20 Again, since the feature is optional, I support defining the mechanism so that InfiniBand infrastructure can run on top of iWARP. But let's also be clear that that the data is application/infrastructure specific (Caitlin was - but I've heard other people imply other claims). The main reason I bring this up is I personally believe that many (most?) protocols designed to run directly on iWARP will have no use for this capability. They'll just embed iWARP parameters inside of their existing application specific exchanges. Examples of this include the newly submitted iSER Internet Draft (http://www.ietf.org/internet-drafts/draft-ko-iwarp-iser-00.txt) and work being done on SDP (Internet Draft expected in about a month). Jim > -----Original Message----- > From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of > Caitlin Bestler > Sent: Tuesday, September 30, 2003 7:36 AM > To: rddp@ietf.org > Cc: David Black > Subject: [rddp] Connection Startup >=20 >=20 > On Monday, September 29, 2003, at 02:12 PM, Black_David@emc.com wrote: >=20 > > Now that I've done my job in getting the problem statement > > and architecture documents to the ADs for publication, it's > > high time for the WG to get back to work from summer > > vacation ... > > > > ... I've seen very little list traffic on technical issues > > over the past month or so, and if I were to judge solely > > by that, I'd have a hard time justifying meeting time > > in Minneapolis. Now, I know better - we have serious open > > technical issues, and hence I'd like to see some comments/ > > proposals/discussion on at least the following: > > > > (1) Connection startup. After all the discussion about > > minimization of round trips, I was shocked to see > > a 3 round-trip startup sequence presented in Vienna. > > The MPA draft authors are responsible for getting > > this down to something more reasonable, and comments > > on the list about how it should be done are welcome. >=20 > With the introduction of the start frame, there is no > need for extra delays during connection setup. What is > proposed works fine, the only adjustment required is > to remove some of the ordering rules. They are not > necessary and can increase the number of round trips. >=20 > A quick review: >=20 > Starting MPA mode has always been easy when both end > naturally know the point in the TCP stream where MPA > should begin. >=20 > This is easily accomplished when that start point is > zero (i.e., the stream is placed in MPA mode immediately) > or at the conclusion of an existing stream-mode negotiation > (as is proposed for iSER). >=20 > The problem case that was raised earlier was when the > need for negotiation is RDMA specific. Specifically, > some private data must be exchanged between the ULP > peers in order to ensure that the RDMA Endpoints are > selected/configured compatibly. >=20 > Earlier I had proposed including Private Data within > the MPA Start Frame to accomplish this. The MPA draft > authors counter-suggested an optional, but standard, > negotiation frame that could proceed the MPA Start > frame. Implicitly, the motivation for separating the > negotiation frame from the start frame was to allow > for the negotiation frame to be handled by drivers > and/or middleware rather than by the hardware/firmware. >=20 > While I still think the single Start Frame with > variable length Private Data is a better solution, > the optional negotiation frame is an acceptable > solution once unnecessary ordering rules are removed. >=20 > The key problem of *not* having a standard method > to exchange Private Data is that without one you cannot > exchnage variable length Private Data without doing a > very tricky round-trip up to the ULP immediately before > entering MPA mode. >=20 > Consider the case where there is a need to send a variable > length message immediately before the MPA Start Frame. > Without a standard format, the ULP must consume and > parse those bytes. And *then* place the stream in MPA > receive mode. >=20 > That either calls for a byte-by-byte fetch from the stream > and/or a putback capability. Either is contrary to the goal > of optimizing performance on non-MPA TCP streams. >=20 > A standardized negotiation frame allows the ULP peers to > place their streams in MPA mode (and bind them with RDMA > endpoints) before the variable length private data message. >=20 > This works well under all of the following scenarios: >=20 > Instant Startup: ULP peers have pre-designated the connection > to be in MPA mode. They each send an MPA Start Frame immediately > to conform this. >=20 > Post-streaming-mode Startup: After conducting streaming mode > negotiations over the TCP connections, the ULP peers have reached > the same state as an Instant Startup. They can each send MPA > Start frames immediately. The end that completed the negotiation > can even place its MPA Start Frame in the same TCP segment as > its final streaming mode response. >=20 > IB CM-compatible startup: > Active side sends a Negotiation Frame with its private data. > It also pre-designates the RDMA endpoint to be used. >=20 > Passive side consumes the Negotiation Frame and passes it to > the ULP as an event. >=20 > Passive side uses the private data to select/configure its > endpoint. It responds by sending its responding negotiation > frame, associating its endpoint and sending its MPA Start > Frame. The MPA Start Frame SHOULD be in the same TCP segment > as the Negotiation Frame when possible. >=20 > Active Side consumes Negotiation Frame, and immediately places > the TCP connection in MPA mode (sending its MPA Start Frame > and consuming the one sent to it). The previously designated > RDMA endpoint is associated, and will handle all DDP Segments > that are after the MPA Start Frame. The peer MPA Start frame > can be consumer immediately. The private data from the response > negotiation frame is reported to the ULP. >=20 >=20 >=20 >=20 > The simplified rules therefore are: >=20 > - An implementation MUST NOT send the MPA Start Frame until > it is ready to process FULPDUs starting at the agreed > point in the TCP stream. > - An implementation MUST NOT send FULPDUs prior to receiving > an MPA Start Frame from its peer. >=20 > These two rules ensure that there is an RDMA Endpoint > associated with the stream before any DDP Segments are sent. >=20 > - An implementation MUST NOT send FULPDUs earlier in its > output TCP Stream than the MPA Start Frame. > - An implementation MAY send zero or more Negotiation Frames > prior to the MPA Start Frame. > - If an implementation does not receive the exepected > MPA Start Frame at the agreed point in the TCP Stream > it MUST terminate the connection. >=20 >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Wed Oct 1 23:44:25 2003 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 XAA17392 for ; Wed, 1 Oct 2003 23:44:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4uNm-0000WQ-Dr for rddp-archive@odin.ietf.org; Wed, 01 Oct 2003 23:44:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h923i2Id002000 for rddp-archive@odin.ietf.org; Wed, 1 Oct 2003 23:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4uNm-0000WB-AI for rddp-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 23:44: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 XAA17372 for ; Wed, 1 Oct 2003 23:43:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4uNj-0001oC-00 for rddp-web-archive@ietf.org; Wed, 01 Oct 2003 23:43:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4uNj-0001o8-00 for rddp-web-archive@ietf.org; Wed, 01 Oct 2003 23:43:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4uNk-0000Vb-Tz; Wed, 01 Oct 2003 23:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4uMp-0000Tf-0t for rddp@optimus.ietf.org; Wed, 01 Oct 2003 23:43:03 -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 XAA17359 for ; Wed, 1 Oct 2003 23:42:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4uMm-0001ns-00 for rddp@ietf.org; Wed, 01 Oct 2003 23:43:00 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1A4uMm-0001nP-00 for rddp@ietf.org; Wed, 01 Oct 2003 23:43:00 -0400 Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Wed, 1 Oct 2003 20:42:38 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Wed, 1 Oct 2003 20:42:27 -0700 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 01 Oct 2003 20:42:30 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Oct 2003 20:42:56 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Oct 2003 20:42:32 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 1 Oct 2003 20:42:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] Re: Invalidation Date: Wed, 1 Oct 2003 20:42:27 -0700 Message-ID: Thread-Topic: [rddp] Re: Invalidation thread-index: AcOHz5e/V0lsB/VQRHO4EjWGArO7/AAxvipA From: "Jim Pinkerton" To: "Caitlin Bestler" , Cc: "David Black" X-OriginalArrivalTime: 02 Oct 2003 03:42:29.0269 (UTC) FILETIME=[34238C50:01C38897] Content-Transfer-Encoding: quoted-printable 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable David, >From reading your email, it sounds like you are thinking there is a layering violation? Is that your point? If so, I'd claim otherwise. Clearly there is an interface above DDP to enable a buffer to be mapped to an STag, and just as clearly there is an interface to invalidate that mapping. Thus to me all that is happening is RDMAP, as the ULP to DDP, is calling the invalidate mechanism for a DDP STag. On Caitlin's points below, I agree with the Quirk summary, and also agree that we should make it clear that the local peer can choose to configure an STag to never be invalidated (regardless of whether an invalidate STag is received). This is effectively a DOS attack otherwise (and I'll add it to the security draft). Jim > -----Original Message----- > From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of > Caitlin Bestler > Sent: Tuesday, September 30, 2003 8:14 AM > To: rddp@ietf.org > Cc: David Black > Subject: [rddp] Re: Invalidation >=20 >=20 > On Monday, September 29, 2003, at 02:12 PM, Black_David@emc.com wrote: >=20 > > (2) Invalidation. We have a lingering issue from way back > > when that RDMAP is handling invalidation of STags, > > which are DDP level resources. This needs some > > serious examination in this forum. >=20 > I'm not sure I remember anything that qualifies as an > "issue". There are certainly some quirks that relate to > the fact that the invalidation is inherently asynchronous > because it is processed on the "completion track" and at > least theoretically by a different layer (and hence potentially > as well). >=20 > Quirk #1: Invalidation is not a fence. "Later" DDP Segments > may be placed prior to the invalidation -- even if received > in order. Invalidation offers no guarantees to the sender, > only to the receiver. And the receiver is only guaranteed > that there will be no further placements *when the notice > of the invalidation is delivered*. The only guarantee about > what was placed at that point is that *earlier* DDP segments > will have been placed. There is no guarantee that *later* > DDP segments were *not* placed. >=20 > Quirk #2: Invalidation may or may not disrupt an in-process > RDMA Read. That is, there is no specification on *when* an > RDMA Read engine translates STags. >=20 >=20 >=20 > The last issue is that the current wording does not allow > a local implementation to suppress remote invalidation on > specific tags. This essentially prevents exporting STags > that are associated with permanent data structures such > as Memory Regions (as opposed to windows). That should be > fixed. >=20 > In general, remote invalidation should not be viewed as > providing any guarantees to the remote side. It is a > service to the local ULP. While it ought to remain > mandatory to implement, the local ULP should have > the option of not using it for a specific STag. >=20 >=20 >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Oct 2 00:01:26 2003 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 AAA17926 for ; Thu, 2 Oct 2003 00:01:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ueF-00013j-RB for rddp-archive@odin.ietf.org; Thu, 02 Oct 2003 00:01:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92413GH004060 for rddp-archive@odin.ietf.org; Thu, 2 Oct 2003 00:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ueF-00013P-MD for rddp-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 00:01:03 -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 AAA17896 for ; Thu, 2 Oct 2003 00:00:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4ueD-0001ym-00 for rddp-web-archive@ietf.org; Thu, 02 Oct 2003 00:01:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4ueC-0001yj-00 for rddp-web-archive@ietf.org; Thu, 02 Oct 2003 00:01:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ueD-00012s-JI; Thu, 02 Oct 2003 00:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4udI-00011H-H3 for rddp@optimus.ietf.org; Thu, 02 Oct 2003 00:00:04 -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 XAA17877 for ; Wed, 1 Oct 2003 23:59:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4udF-0001yZ-00 for rddp@ietf.org; Thu, 02 Oct 2003 00:00:01 -0400 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1A4udF-0001yK-00 for rddp@ietf.org; Thu, 02 Oct 2003 00:00:01 -0400 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Oct 2003 20:59:30 -0700 Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 01 Oct 2003 20:59:30 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Oct 2003 20:59:57 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Oct 2003 20:59:33 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 1 Oct 2003 20:59:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] Re: Invalidation Date: Wed, 1 Oct 2003 20:59:25 -0700 Message-ID: Thread-Topic: [rddp] Re: Invalidation thread-index: AcOHz5e/V0lsB/VQRHO4EjWGArO7/AAxvipAAACuyHA= From: "Jim Pinkerton" To: "Jim Pinkerton" , "Caitlin Bestler" , Cc: "David Black" X-OriginalArrivalTime: 02 Oct 2003 03:59:29.0427 (UTC) FILETIME=[94334E30:01C38899] Content-Transfer-Encoding: quoted-printable 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Here's proposed text to address this in the security draft. Note that the threat actually has nothing to do with whether the STag is long-lived or not - the key issue is sharing it across multiple connections. 7.5.5 Remote Invalidation of an STag Shared Across Multiple Connections If a Local Peer has enabled an STag for remote access, the Remote Peer could attempt to invalidate the STag by using the RDMAP Send with Invalidate or Send with SE and Invalidate Message. If the STag is only valid on the current connection (NS-NT or NS-RT, S-NT), then the only side effect is that the Remote Peer can no longer use the STag, thus there are no security issues. If the STag is valid across multiple connections, then the Remote Peer can prevent other connections from using that STag by using the remote invalidate functionality.=20 Thus for trust models that involve shared local STags across multiple connections connecting to mutually untrusted Remote Peers, the invalidate STag capability SHOULD be disabled for the shared STag. > -----Original Message----- > From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Jim > Pinkerton > Sent: Wednesday, October 01, 2003 8:42 PM > To: Caitlin Bestler; rddp@ietf.org > Cc: David Black > Subject: RE: [rddp] Re: Invalidation >=20 >=20 > David, >=20 > From reading your email, it sounds like you are thinking there is a > layering violation? Is that your point? >=20 > If so, I'd claim otherwise. Clearly there is an interface above DDP to > enable a buffer to be mapped to an STag, and just as clearly there is an > interface to invalidate that mapping. Thus to me all that is happening > is RDMAP, as the ULP to DDP, is calling the invalidate mechanism for a > DDP STag. >=20 > On Caitlin's points below, I agree with the Quirk summary, and also > agree that we should make it clear that the local peer can choose to > configure an STag to never be invalidated (regardless of whether an > invalidate STag is received). This is effectively a DOS attack otherwise > (and I'll add it to the security draft). >=20 >=20 >=20 > Jim >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of > > Caitlin Bestler > > Sent: Tuesday, September 30, 2003 8:14 AM > > To: rddp@ietf.org > > Cc: David Black > > Subject: [rddp] Re: Invalidation > > > > > > On Monday, September 29, 2003, at 02:12 PM, Black_David@emc.com wrote: > > > > > (2) Invalidation. We have a lingering issue from way back > > > when that RDMAP is handling invalidation of STags, > > > which are DDP level resources. This needs some > > > serious examination in this forum. > > > > I'm not sure I remember anything that qualifies as an > > "issue". There are certainly some quirks that relate to > > the fact that the invalidation is inherently asynchronous > > because it is processed on the "completion track" and at > > least theoretically by a different layer (and hence potentially > > as well). > > > > Quirk #1: Invalidation is not a fence. "Later" DDP Segments > > may be placed prior to the invalidation -- even if received > > in order. Invalidation offers no guarantees to the sender, > > only to the receiver. And the receiver is only guaranteed > > that there will be no further placements *when the notice > > of the invalidation is delivered*. The only guarantee about > > what was placed at that point is that *earlier* DDP segments > > will have been placed. There is no guarantee that *later* > > DDP segments were *not* placed. > > > > Quirk #2: Invalidation may or may not disrupt an in-process > > RDMA Read. That is, there is no specification on *when* an > > RDMA Read engine translates STags. > > > > > > > > The last issue is that the current wording does not allow > > a local implementation to suppress remote invalidation on > > specific tags. This essentially prevents exporting STags > > that are associated with permanent data structures such > > as Memory Regions (as opposed to windows). That should be > > fixed. > > > > In general, remote invalidation should not be viewed as > > providing any guarantees to the remote side. It is a > > service to the local ULP. While it ought to remain > > mandatory to implement, the local ULP should have > > the option of not using it for a specific STag. > > > > > > > > _______________________________________________ > > rddp mailing list > > rddp@ietf.org > > https://www1.ietf.org/mailman/listinfo/rddp >=20 >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Oct 2 10:49:29 2003 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 KAA22850 for ; Thu, 2 Oct 2003 10:49:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54lO-0003PA-98 for rddp-archive@odin.ietf.org; Thu, 02 Oct 2003 10:49:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92En6dE013084 for rddp-archive@odin.ietf.org; Thu, 2 Oct 2003 10:49:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54lO-0003M1-1J for rddp-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 10:49:06 -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 KAA22785 for ; Thu, 2 Oct 2003 10:48:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A54lI-0001SW-00 for rddp-web-archive@ietf.org; Thu, 02 Oct 2003 10:49:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A54lI-0001ST-00 for rddp-web-archive@ietf.org; Thu, 02 Oct 2003 10:49:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54lI-0003LP-Dh; Thu, 02 Oct 2003 10:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54kq-0003IU-6X for rddp@optimus.ietf.org; Thu, 02 Oct 2003 10:48:32 -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 KAA22680 for ; Thu, 2 Oct 2003 10:48:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A54kn-0001S0-00 for rddp@ietf.org; Thu, 02 Oct 2003 10:48:29 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 1A54kn-0001RR-00 for rddp@ietf.org; Thu, 02 Oct 2003 10:48:29 -0400 Received: from asomi.com (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 9E0CE245D1A; Thu, 2 Oct 2003 10:48:17 -0400 (EDT) Date: Thu, 2 Oct 2003 09:48:30 -0500 Subject: Re: [rddp] Re: Invalidation Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: , "David Black" To: "Jim Pinkerton" From: Caitlin Bestler In-Reply-To: Message-Id: <7CED44B6-F4E7-11D7-9D7F-003065D48EE0@asomi.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wednesday, October 1, 2003, at 10:59 PM, Jim Pinkerton wrote: > Here's proposed text to address this in the security draft. Note that > the threat actually has nothing to do with whether the STag is > long-lived or not - the key issue is sharing it across multiple > connections. > > > 7.5.5 Remote Invalidation of an STag Shared Across Multiple > Connections > > If a Local Peer has enabled an STag for remote access, the Remote Peer > could attempt to invalidate the STag by using the RDMAP Send with > Invalidate or Send with SE and Invalidate Message. If the STag is only > valid on the current connection (NS-NT or NS-RT, S-NT), then the only > side effect is that the Remote Peer can no longer use the STag, thus > there are no security issues. > > If the STag is valid across multiple connections, then the Remote Peer > can prevent other connections from using that STag by using the remote > invalidate functionality. > > Thus for trust models that involve shared local STags across multiple > connections connecting to mutually untrusted Remote Peers, the > invalidate STag capability SHOULD be disabled for the shared STag. But of course the ULP MAY have other reasons to disable remote invalidation that are beyond the ability of transport layer designers to comprehend. In other words, part of the definition of "ULP" is that it is allowed to do things for stupid, I mean application-specific, reasons. The language proposed sounds fine, and covers the *justifying* reason well. After all, a Memory Region is just one type of shared STag. But we also need permission to do this in the DDP document. Currently it specifies that after a remote invalidation that the STag MUST be invalid until it is re-instated by the ULP. That should be reduced to a SHOULD, with a comments that local interfaces MAY offer variants such as not recognizing an invalidation. The wire-protocol issue is what the response to a blocked remote invalidate should be: a) ignore it. The remote end doesn't have to know that the STag is still valid, because it won't be attempting to use it anyway. b) treat it as an access violation and terminate the connection. I favor A, whether thinking as an application designer or as an RNIC designer. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Oct 2 11:00:25 2003 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 LAA23866 for ; Thu, 2 Oct 2003 11:00:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54w0-0004ct-Dc for rddp-archive@odin.ietf.org; Thu, 02 Oct 2003 11:00:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92F04HQ017779 for rddp-archive@odin.ietf.org; Thu, 2 Oct 2003 11:00:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54w0-0004cg-8F for rddp-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 11:00:04 -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 KAA23830 for ; Thu, 2 Oct 2003 10:59:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A54vx-0001dz-00 for rddp-web-archive@ietf.org; Thu, 02 Oct 2003 11:00:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A54vx-0001dw-00 for rddp-web-archive@ietf.org; Thu, 02 Oct 2003 11:00:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54vy-0004cI-Pf; Thu, 02 Oct 2003 11:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54v3-0004Vi-Hv for rddp@optimus.ietf.org; Thu, 02 Oct 2003 10:59:05 -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 KAA23782 for ; Thu, 2 Oct 2003 10:58:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A54v0-0001d4-00 for rddp@ietf.org; Thu, 02 Oct 2003 10:59:02 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 1A54v0-0001ce-00 for rddp@ietf.org; Thu, 02 Oct 2003 10:59:02 -0400 Received: from asomi.com (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 5DE46245644; Thu, 2 Oct 2003 10:59:02 -0400 (EDT) Date: Thu, 2 Oct 2003 09:59:16 -0500 Subject: Re: [rddp] Connection Startup Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: , "David Black" To: "Jim Pinkerton" From: Caitlin Bestler In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 From exim@www1.ietf.org Thu Oct 2 17:52:23 2003 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 RAA27122 for ; Thu, 2 Oct 2003 17:52: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 1A5BMh-00059D-Gz for rddp-archive@odin.ietf.org; Thu, 02 Oct 2003 17:52:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Lq3iF019783 for rddp-archive@odin.ietf.org; Thu, 2 Oct 2003 17:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5BMh-000590-Bb for rddp-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 17:52:03 -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 RAA27111 for ; Thu, 2 Oct 2003 17:51:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5BMe-0007Dy-00 for rddp-web-archive@ietf.org; Thu, 02 Oct 2003 17:52:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5BMe-0007Dv-00 for rddp-web-archive@ietf.org; Thu, 02 Oct 2003 17:52:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5BMf-00058d-KJ; Thu, 02 Oct 2003 17:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5BMS-00058R-Ec for rddp@optimus.ietf.org; Thu, 02 Oct 2003 17:51:48 -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 RAA27107 for ; Thu, 2 Oct 2003 17:51:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5BMP-0007Dq-00 for rddp@ietf.org; Thu, 02 Oct 2003 17:51:45 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 1A5BMP-0007Dn-00 for rddp@ietf.org; Thu, 02 Oct 2003 17:51:45 -0400 Received: from asomi.com (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 0E09F245B6A; Thu, 2 Oct 2003 17:51:34 -0400 (EDT) Date: Thu, 2 Oct 2003 16:51:49 -0500 Subject: Re: [rddp] Re: Invalidation Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: , "David Black" To: "Jim Pinkerton" From: Caitlin Bestler In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wednesday, October 1, 2003, at 10:59 PM, Jim Pinkerton wrote: > Here's proposed text to address this in the security draft. Note that > the threat actually has nothing to do with whether the STag is > long-lived or not - the key issue is sharing it across multiple > connections. > > > 7.5.5 Remote Invalidation of an STag Shared Across Multiple > Connections > > If a Local Peer has enabled an STag for remote access, the Remote Peer > could attempt to invalidate the STag by using the RDMAP Send with > Invalidate or Send with SE and Invalidate Message. If the STag is only > valid on the current connection (NS-NT or NS-RT, S-NT), then the only > side effect is that the Remote Peer can no longer use the STag, thus > there are no security issues. > > If the STag is valid across multiple connections, then the Remote Peer > can prevent other connections from using that STag by using the remote > invalidate functionality. > > Thus for trust models that involve shared local STags across multiple > connections connecting to mutually untrusted Remote Peers, the > invalidate STag capability SHOULD be disabled for the shared STag. Thinking about this a bit more in the context of the Security draft, the most critical advise remains that an STag should have no wider of a scope than the ULP requires. Hence, the ULP SHOULD have the ability to make an STag valid only on those DDP Streams that are associated with a specific session, or are otherwise presumed to have a trusting relationship with each other. In other words, if there is a basis to assume that the peers for multiple remote peers can be trusted to share an STag, they can probably be trusted to invalidate it. The major exception that I can think of would be an STag that was enabled for RDMA Read usage only. The Data Source could be publishing status data, for example, that any client could read at its convenience. In that case, just as none of them are trusted to write to the data, none would be trusted to invalidate the STag. I also note that the inability to support dynamically bound STags across multiple DDP Streams is, in my opinion, a critical flaw in the RDMAC proposed iWarp verbs. It would also be easily corrected by replacing the "QP ID" used in validating a bound STag with a "QP Set ID". By default each QP would belong to its own QP Set. On the original topic, a "data publishing STag" is just one example of many valid *local* reasons to disallow remote invalidation. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Oct 3 16:17:24 2003 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 QAB25136 for ; Fri, 3 Oct 2003 16:17:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5WMJ-0001De-2e for rddp-archive@odin.ietf.org; Fri, 03 Oct 2003 16:17:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93KH3BN004682 for rddp-archive@odin.ietf.org; Fri, 3 Oct 2003 16:17:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5WMI-0001DR-RN for rddp-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 16:17: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 QAA25088 for ; Fri, 3 Oct 2003 16:16:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5WMG-0005rL-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 16:17:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5WMG-0005rH-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 16:17:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5WMG-0001Cx-TX; Fri, 03 Oct 2003 16:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5WLr-0001CS-7S for rddp@optimus.ietf.org; Fri, 03 Oct 2003 16:16:37 -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 QAA25018 for ; Fri, 3 Oct 2003 16:16:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5WLp-0005qe-00 for rddp@ietf.org; Fri, 03 Oct 2003 16:16:33 -0400 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1A5WLo-0005pk-00 for rddp@ietf.org; Fri, 03 Oct 2003 16:16:32 -0400 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Oct 2003 13:16:01 -0700 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 03 Oct 2003 13:16:01 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 3 Oct 2003 13:15:59 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 3 Oct 2003 13:16:01 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 3 Oct 2003 13:15:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] Connection Startup Date: Fri, 3 Oct 2003 13:16:10 -0700 Message-ID: Thread-Topic: [rddp] Connection Startup thread-index: AcOI9a+MeMl/v+2qQxqAsrvFhfCQwgA8d6qA From: "Jim Pinkerton" To: "Caitlin Bestler" Cc: , "David Black" X-OriginalArrivalTime: 03 Oct 2003 20:15:59.0963 (UTC) FILETIME=[294B5AB0:01C389EB] Content-Transfer-Encoding: quoted-printable 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I don't agree with some of your characterizations. My reason for raising this issue is to not stop the definition of the handshake - it is to make it clear on what the technical benefits are, and exactly who benefits. First, I agree that for DAT (which was defined for InfiniBand, as well as older, proprietary MAC layer encapsulations of RDMA) there is a need, at least as DAT is currently defined. For NFS over RDMA, there is no need to define the handshake at this layer, unless you're trying to fit in on top of DAT. If that is the case, then I agree you need it. For support for SCTP or TCP encapsulations, there is no need for the optional handshake. The reason for the handshake is driven by the ULP, not the LLP - thus this becomes a new requirement on the LLP encapsulation of RDMA.=20 The last paragraph of your summary of benefits is unsupported, so far as I can tell. I can envision many ways of implementing things that optimize context switching during connection seteup that has nothing to do the handshake.=20 I also don't see how you can claim the handshake uniquely enables the following: > 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. This paragraph should really read "One of the benefits of DAT is that it allows...". And that to enable DAT, we need a standard way to delineate the record boundary of config information before RDMA endpoints are enabled. Note that iSER essentially uses the same boot start mechanism - send a bit of data, agree on configuration, and then enable RDMA - the only difference is that iSER exchanged the information as part of *their* record delineation mechanism, and this proposal defines it within MPA (i.e. LLP) to make it possible to delineate config information record boundary independent of application protocol. =20 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 >=20 >=20 > On Wednesday, October 1, 2003, at 10:36 PM, Jim Pinkerton wrote: >=20 > > > > 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). > > >=20 > Yes, the intent is to carry opaque messages between the ULP peers > to enable them to select/configure the RDMA endpoints compatibly. >=20 > > 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?". > > >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > > > > > > > Caitlin Bestler - cait@asomi.com - http://asomi.com/ >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Oct 3 16:38:25 2003 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 QAA26749 for ; Fri, 3 Oct 2003 16:38:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Wge-00032K-Fo for rddp-archive@odin.ietf.org; Fri, 03 Oct 2003 16:38:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93Kc4bh011666 for rddp-archive@odin.ietf.org; Fri, 3 Oct 2003 16:38:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Wge-000325-CX for rddp-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 16:38:04 -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 QAA26703 for ; Fri, 3 Oct 2003 16:37:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Wga-0006Ex-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 16:38:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5Wga-0006Eu-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 16:38:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Wgb-00031V-Ns; Fri, 03 Oct 2003 16:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Wg1-0002oQ-OL for rddp@optimus.ietf.org; Fri, 03 Oct 2003 16:37:25 -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 QAA26638 for ; Fri, 3 Oct 2003 16:37:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Wfz-0006Dj-00 for rddp@ietf.org; Fri, 03 Oct 2003 16:37:23 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 1A5Wfz-0006BW-00 for rddp@ietf.org; Fri, 03 Oct 2003 16:37:23 -0400 Received: from asomi.com (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 9642C24568F; Fri, 3 Oct 2003 16:37:22 -0400 (EDT) Date: Fri, 3 Oct 2003 15:37:39 -0500 Subject: Re: [rddp] Connection Startup Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: rddp@ietf.org To: "Jim Pinkerton" From: Caitlin Bestler In-Reply-To: Message-Id: <6E2302FE-F5E1-11D7-9D7F-003065D48EE0@asomi.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Friday, October 3, 2003, at 03:16 PM, Jim Pinkerton wrote: > Note that iSER essentially uses the same boot start mechanism - send a > bit of data, agree on configuration, and then enable RDMA - the only > difference is that iSER exchanged the information as part of *their* > record delineation mechanism, and this proposal defines it within MPA > (i.e. LLP) to make it possible to delineate config information record > boundary independent of application protocol. But iSCSI negotiations are only defined over TCP, hardly LLP neutral. When/if iSCSI/SCTP is defined (as it should have been) the ULP would have to engage in different interactions to negotiate depending on which LLP was in use. The bottom line is that TCP exchanges bytes while SCTP exchanges messages. If you are developing an RDMA specific application then the message orientation is closer to how you will be working once RDMA is established. So having a message-oriented negotiation standard available as an option is a major benefit. It lets the entire application be coded at a "message" layer, not mixing byte streams and messages. It's really early in the process to come to any final conclusions about what is "normal" for RDMA applications. The app developers that I have talked with have had no interest in adding iSER like capabilities to the DAT API. But in any case, I believe we are in full agreement that *both* models need to be supported. Which just disagree over which one should be viewed as "normal". Caitlin Bestler - cait@asomi.com - http://asomi.com/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Oct 3 16:42:23 2003 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 QAA27149 for ; Fri, 3 Oct 2003 16:42: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 1A5WkU-0003Aa-BN for rddp-archive@odin.ietf.org; Fri, 03 Oct 2003 16:42:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93Kg2o7012178 for rddp-archive@odin.ietf.org; Fri, 3 Oct 2003 16:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5WkU-00039S-3g for rddp-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 16:42: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 QAA27113 for ; Fri, 3 Oct 2003 16:41:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5WkR-0006Mn-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 16:41:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5WkR-0006Mi-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 16:41:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5WkT-00038m-0B; Fri, 03 Oct 2003 16:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Wjy-00038G-9L for rddp@optimus.ietf.org; Fri, 03 Oct 2003 16:41:30 -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 QAA27062 for ; Fri, 3 Oct 2003 16:41:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Wjw-0006Ll-00 for rddp@ietf.org; Fri, 03 Oct 2003 16:41:28 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1A5Wjv-0006L5-00 for rddp@ietf.org; Fri, 03 Oct 2003 16:41:27 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Fri, 3 Oct 2003 13:40:58 -0700 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 03 Oct 2003 13:40:57 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Oct 2003 13:40:54 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 3 Oct 2003 13:40:56 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 3 Oct 2003 13:40:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] Re: Invalidation Date: Fri, 3 Oct 2003 13:40:45 -0700 Message-ID: Thread-Topic: [rddp] Re: Invalidation thread-index: AcOI9C/0MjhiDkDNR92Su4j0EYojaAA+OtvQ From: "Jim Pinkerton" To: "Caitlin Bestler" Cc: , "David Black" X-OriginalArrivalTime: 03 Oct 2003 20:40:56.0535 (UTC) FILETIME=[A5521E70:01C389EE] Content-Transfer-Encoding: quoted-printable 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sorry if my proposed text was construed as wanting to change in something in the DDP spec. It was pointed out to me offline, and it certainly wasn't my intention. I'm perfectly fine with saying a remote invalidate MUST invalidate the local STag (as the current DDP draft states) and that this needs to be directly addressed in the security draft for how that effects trust models and mitigations. So here's proposed new text: 7.5.5 Remote Invalidation of an STag Shared Across Multiple Connections If a Local Peer has enabled an STag for remote access, the Remote Peer could attempt to invalidate the STag by using the RDMAP Send with Invalidate or Send with SE and Invalidate Message. If the STag is only valid on the current connection (NS-NT or NS-RT, S-NT), then the only side effect is that the Remote Peer can no longer use the STag, thus there are no security issues. If the STag is valid across multiple connections, then the Remote Peer can prevent other connections from using that STag by using the remote invalidate functionality.=20 Thus for trust models where the Remote Peer may attempt to invalidate the STag prematurely, the application SHOULD NOT allow an STag to be valid across multiple connections. Jim > -----Original Message----- > From: Caitlin Bestler [mailto:cait@asomi.com] > Sent: Thursday, October 02, 2003 7:49 AM > To: Jim Pinkerton > Cc: rddp@ietf.org; David Black > Subject: Re: [rddp] Re: Invalidation >=20 >=20 > On Wednesday, October 1, 2003, at 10:59 PM, Jim Pinkerton wrote: >=20 > > Here's proposed text to address this in the security draft. Note that > > the threat actually has nothing to do with whether the STag is > > long-lived or not - the key issue is sharing it across multiple > > connections. > > > > > > 7.5.5 Remote Invalidation of an STag Shared Across Multiple > > Connections > > > > If a Local Peer has enabled an STag for remote access, the Remote Peer > > could attempt to invalidate the STag by using the RDMAP Send with > > Invalidate or Send with SE and Invalidate Message. If the STag is only > > valid on the current connection (NS-NT or NS-RT, S-NT), then the only > > side effect is that the Remote Peer can no longer use the STag, thus > > there are no security issues. > > > > If the STag is valid across multiple connections, then the Remote Peer > > can prevent other connections from using that STag by using the remote > > invalidate functionality. > > > > Thus for trust models that involve shared local STags across multiple > > connections connecting to mutually untrusted Remote Peers, the > > invalidate STag capability SHOULD be disabled for the shared STag. >=20 > But of course the ULP MAY have other reasons to disable remote > invalidation that are beyond the ability of transport layer > designers to comprehend. In other words, part of the definition > of "ULP" is that it is allowed to do things for stupid, I mean > application-specific, reasons. >=20 > The language proposed sounds fine, and covers the *justifying* > reason well. After all, a Memory Region is just one type of > shared STag. >=20 > But we also need permission to do this in the DDP document. > Currently it specifies that after a remote invalidation that > the STag MUST be invalid until it is re-instated by the ULP. >=20 > That should be reduced to a SHOULD, with a comments that > local interfaces MAY offer variants such as not recognizing > an invalidation. >=20 > The wire-protocol issue is what the response to a blocked > remote invalidate should be: >=20 > a) ignore it. The remote end doesn't have to know that the > STag is still valid, because it won't be attempting to > use it anyway. > b) treat it as an access violation and terminate the connection. >=20 > I favor A, whether thinking as an application designer or as > an RNIC designer. >=20 >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Oct 3 17:08:24 2003 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 RAA29268 for ; Fri, 3 Oct 2003 17:08:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5X9f-000539-It for rddp-archive@odin.ietf.org; Fri, 03 Oct 2003 17:08:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93L83fg019405 for rddp-archive@odin.ietf.org; Fri, 3 Oct 2003 17:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5X9f-00052u-FA for rddp-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 17:08:03 -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 RAA29232 for ; Fri, 3 Oct 2003 17:07:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5X9d-00076Q-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 17:08:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5X9c-00076N-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 17:08:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5X9e-00052X-8S; Fri, 03 Oct 2003 17:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5X9c-000527-Ic for rddp@optimus.ietf.org; Fri, 03 Oct 2003 17:08:00 -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 RAA29229 for ; Fri, 3 Oct 2003 17:07:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5X9a-00076K-00 for rddp@ietf.org; Fri, 03 Oct 2003 17:07:58 -0400 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 1A5X9Z-00075k-00 for rddp@ietf.org; Fri, 03 Oct 2003 17:07:57 -0400 Received: from hawk.corp.netapp.com (hawk [10.10.20.101]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id h93L7K4Z022867; Fri, 3 Oct 2003 14:07:20 -0700 (PDT) Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.10.22.171]) by hawk.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id h93L7KBo002201; Fri, 3 Oct 2003 14:07:20 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [rddp] Connection Startup Date: Fri, 3 Oct 2003 14:05:24 -0700 Message-ID: Thread-Topic: [rddp] Connection Startup Thread-Index: AcOI9a+MeMl/v+2qQxqAsrvFhfCQwgA8d6qAAAJbiJA= From: "Kanevsky, Arkady" To: "Jim Pinkerton" , "Caitlin Bestler" Cc: , "David Black" Content-Transfer-Encoding: quoted-printable 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > From: Jim Pinkerton [mailto:jpink@windows.microsoft.com]=20 > First, I agree that for DAT (which was defined for=20 > InfiniBand, as well as older, proprietary MAC layer=20 > encapsulations of RDMA) there is a need, at least as DAT is=20 > currently defined. There is a requirement for current applications using existing RDMA transport technology to rely on the RDMA transport provided connection establishment. Some applications can define their own protocol for connection establishment. SDP is an example of it. DAT quotation is a red hearing since it is just an API and not a protocol or an appication. Arkady Arkady Kanevsky email: arkady@netapp.com Network Appliance phone: 781-768-5395 375 Totten Pond Rd. Fax: 781-895-1195 3rd Floor http: www.netapp.com Waltham, MA 02451-2010 general phone: 781-768-5300 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Oct 3 17:40:27 2003 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 RAA00488 for ; Fri, 3 Oct 2003 17:40:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Xeg-0006gh-6A for rddp-archive@odin.ietf.org; Fri, 03 Oct 2003 17:40:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93Le50C025690 for rddp-archive@odin.ietf.org; Fri, 3 Oct 2003 17:40:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Xee-0006gH-Ib for rddp-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 17:40:04 -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 RAA00462 for ; Fri, 3 Oct 2003 17:39:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Xec-0007Ul-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 17:40:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5Xeb-0007Ui-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 17:40:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Xed-0006fo-7F; Fri, 03 Oct 2003 17:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Xe0-0006eo-Ct for rddp@optimus.ietf.org; Fri, 03 Oct 2003 17:39:24 -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 RAA00419 for ; Fri, 3 Oct 2003 17:39:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Xdx-0007Tp-00 for rddp@ietf.org; Fri, 03 Oct 2003 17:39:21 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1A5Xdx-0007TU-00 for rddp@ietf.org; Fri, 03 Oct 2003 17:39:21 -0400 Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Fri, 3 Oct 2003 14:38:52 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 3 Oct 2003 14:38:49 -0700 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 03 Oct 2003 14:38:50 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Oct 2003 14:38:46 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 3 Oct 2003 14:38:49 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 3 Oct 2003 14:38:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] Connection Startup Date: Fri, 3 Oct 2003 14:38:46 -0700 Message-ID: Thread-Topic: [rddp] Connection Startup thread-index: AcOJ7h3YqtDcnPKfQHOMzi1cuPVY1QAALm3Q From: "Jim Pinkerton" To: "Caitlin Bestler" Cc: X-OriginalArrivalTime: 03 Oct 2003 21:38:49.0791 (UTC) FILETIME=[BB8AECF0:01C389F6] Content-Transfer-Encoding: quoted-printable 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I agree with your conclusion that we both support the capability.=20 I think we still disagree on the use of the capability, let alone who will use it. Specifically I don't see how the capability can solve transport layer independence at all. Many of the issues must be dealt with before the connection is even setup (like will the LLP provide datagrams or streams, or does the transport provide reliability, etc). The handshake doesn't address those issues. It does enable a middleware library to attempt to address them, and push through some private data to try to set things up between itself and its peer at the remote end. Jim > -----Original Message----- > From: Caitlin Bestler [mailto:cait@asomi.com] > Sent: Friday, October 03, 2003 1:38 PM > To: Jim Pinkerton > Cc: rddp@ietf.org > Subject: Re: [rddp] Connection Startup >=20 >=20 > On Friday, October 3, 2003, at 03:16 PM, Jim Pinkerton wrote: >=20 > > Note that iSER essentially uses the same boot start mechanism - send a > > bit of data, agree on configuration, and then enable RDMA - the only > > difference is that iSER exchanged the information as part of *their* > > record delineation mechanism, and this proposal defines it within MPA > > (i.e. LLP) to make it possible to delineate config information record > > boundary independent of application protocol. >=20 >=20 > But iSCSI negotiations are only defined over TCP, hardly LLP neutral. >=20 > When/if iSCSI/SCTP is defined (as it should have been) the ULP would > have to engage in different interactions to negotiate depending on > which LLP was in use. The bottom line is that TCP exchanges bytes > while SCTP exchanges messages. >=20 > If you are developing an RDMA specific application then the message > orientation is closer to how you will be working once RDMA is > established. > So having a message-oriented negotiation standard available as an > option is a major benefit. It lets the entire application be coded > at a "message" layer, not mixing byte streams and messages. >=20 > It's really early in the process to come to any final conclusions > about what is "normal" for RDMA applications. The app developers > that I have talked with have had no interest in adding iSER like > capabilities to the DAT API. >=20 > But in any case, I believe we are in full agreement that *both* > models need to be supported. Which just disagree over which one > should be viewed as "normal". >=20 >=20 > Caitlin Bestler - cait@asomi.com - http://asomi.com/ >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Oct 3 17:50:24 2003 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 RAA00744 for ; Fri, 3 Oct 2003 17:50:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5XoK-0006vi-E7 for rddp-archive@odin.ietf.org; Fri, 03 Oct 2003 17:50:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93Lo4bh026632 for rddp-archive@odin.ietf.org; Fri, 3 Oct 2003 17:50:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5XoK-0006vT-AO for rddp-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 17:50:04 -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 RAA00736 for ; Fri, 3 Oct 2003 17:49:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5XoH-0007bi-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 17:50:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5XoH-0007bf-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 17:50:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5XoI-0006v3-R8; Fri, 03 Oct 2003 17:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5XnN-0006sW-C5 for rddp@optimus.ietf.org; Fri, 03 Oct 2003 17:49:05 -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 RAA00706 for ; Fri, 3 Oct 2003 17:48:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5XnK-0007b6-00 for rddp@ietf.org; Fri, 03 Oct 2003 17:49:02 -0400 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1A5XnK-0007ay-00 for rddp@ietf.org; Fri, 03 Oct 2003 17:49:02 -0400 Received: from mail5.microsoft.com ([157.54.6.156]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Oct 2003 14:48:31 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Fri, 3 Oct 2003 14:48:31 -0700 Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 03 Oct 2003 14:48:31 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Oct 2003 14:48:32 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Oct 2003 14:48:31 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 3 Oct 2003 14:48:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] Connection Startup Date: Fri, 3 Oct 2003 14:48:30 -0700 Message-ID: Thread-Topic: [rddp] Connection Startup thread-index: AcOI9a+MeMl/v+2qQxqAsrvFhfCQwgA8d6qAAAJbiJAAAX0acA== From: "Jim Pinkerton" To: X-OriginalArrivalTime: 03 Oct 2003 21:48:31.0262 (UTC) FILETIME=[16205BE0:01C389F8] Content-Transfer-Encoding: quoted-printable 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > DAT quotation is a red hearing since it is just an API and not a > protocol or an appication. >=20 My point exactly. But for probably the opposite reasons than you intended=20 :-) > There is a requirement for current applications using existing RDMA > transport technology > to rely on the RDMA transport provided connection establishment. I agree there as well - where "current applications using existing RDMA transport technology" is a euphamism for porting InfiniBand apps to iWARP. The reason I bring this up so strongly is for *new* protocols, which are designed to run on top of IWARP, and don't care about compatiblity with InfiniBand, I see no need for this capability. It's far more optimal to embed their config data in their existing configuration handshakes, and not add a new round-trip handshake. It's specifically because I do care about enabling "current applications using existing RDMA transport technology" that I think this capability should be supported - it's a technology to bridge existing apps to iWARP. Oh, and it's also a technology that enables an existing API to work as well... Jim > -----Original Message----- > From: Kanevsky, Arkady [mailto:Arkady.Kanevsky@netapp.com] > Sent: Friday, October 03, 2003 2:05 PM > To: Jim Pinkerton; Caitlin Bestler > Cc: rddp@ietf.org; David Black > Subject: RE: [rddp] Connection Startup >=20 > > From: Jim Pinkerton [mailto:jpink@windows.microsoft.com] > > First, I agree that for DAT (which was defined for > > InfiniBand, as well as older, proprietary MAC layer > > encapsulations of RDMA) there is a need, at least as DAT is > > currently defined. >=20 > There is a requirement for current applications using existing RDMA > transport technology > to rely on the RDMA transport provided connection establishment. > Some applications can define their own protocol for connection > establishment. > SDP is an example of it. >=20 > DAT quotation is a red hearing since it is just an API and not a > protocol or an appication. >=20 > Arkady >=20 >=20 > Arkady Kanevsky email: arkady@netapp.com > Network Appliance phone: 781-768-5395 > 375 Totten Pond Rd. Fax: 781-895-1195 > 3rd Floor http: www.netapp.com > Waltham, MA 02451-2010 general phone: > 781-768-5300 >=20 >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Oct 3 18:34:21 2003 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 SAA02888 for ; Fri, 3 Oct 2003 18:34:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5YUs-00007j-6L for rddp-archive@odin.ietf.org; Fri, 03 Oct 2003 18:34:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93MY2dJ000475 for rddp-archive@odin.ietf.org; Fri, 3 Oct 2003 18:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5YUs-00007a-0B for rddp-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 18:34: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 SAA02877 for ; Fri, 3 Oct 2003 18:33:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5YUo-0000Cu-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 18:33:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5YUo-0000Cr-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 18:33:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5YUq-00007D-J4; Fri, 03 Oct 2003 18:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5YUM-00006V-88 for rddp@optimus.ietf.org; Fri, 03 Oct 2003 18:33:30 -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 SAA02874 for ; Fri, 3 Oct 2003 18:33:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5YUJ-0000Cn-00 for rddp@ietf.org; Fri, 03 Oct 2003 18:33:27 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 1A5YUI-0000Ce-00 for rddp@ietf.org; Fri, 03 Oct 2003 18:33:26 -0400 Received: from asomi.com (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 9B5F82448F1; Fri, 3 Oct 2003 18:33:27 -0400 (EDT) Date: Fri, 3 Oct 2003 17:33:45 -0500 Subject: Re: [rddp] Connection Startup Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: rddp@ietf.org To: "Jim Pinkerton" From: Caitlin Bestler In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Friday, October 3, 2003, at 04:48 PM, Jim Pinkerton wrote: > The reason I bring this up so strongly is for *new* protocols, which > are > designed to run on top of IWARP, and don't care about compatiblity with > InfiniBand, I see no need for this capability. It's far more optimal to > embed their config data in their existing configuration handshakes, and > not add a new round-trip handshake. That is a valid concern when adding an RDMA mode to an *existing* protocol, such as iSCSI. And the number of *existing* protocols that are LLP neutral is, well, pretty much zero. Use of an RDMA negotiation message *after* other negotiations would indeed be a wasteful additional round-trip. The intent is to support applications that only need minimal simple parameters exchanges in order to establish the session. When this topic has been discussed in the DAT Collaborative, there has been little interest in engaging in more complex session setup. The only thing that *must* be negotiated before enabling RDMA is the essential RDMA configuration (identifying any existing session, RDMA read credits, maximum untagged message size, etc.) to the extent that it is not pre-dictated as constants for that ULP. The general conclusion I have seen application developers who are working on an RDMA specific applications is that complex detailed negotiations can be done *after* the connection is established. Now you can argue that they were merely thinking that way because that is the only model that InfiniBand supported. Or perhaps, that is the only model that InfiniBand supported because it is a fine model that meets the needs of ULP designers who are assuming RDMA capability. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Oct 3 19:33:24 2003 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 TAA04117 for ; Fri, 3 Oct 2003 19:33: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 1A5ZPz-0002Ba-0b for rddp-archive@odin.ietf.org; Fri, 03 Oct 2003 19:33:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93NX2cX008396 for rddp-archive@odin.ietf.org; Fri, 3 Oct 2003 19:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5ZPy-0002BL-Rn for rddp-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 19:33: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 TAA04114 for ; Fri, 3 Oct 2003 19:32:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5ZPx-0000fo-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 19:33:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5ZPw-0000fl-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 19:33:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5ZPx-0002Av-E5; Fri, 03 Oct 2003 19:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5ZPk-0002Ah-PF for rddp@optimus.ietf.org; Fri, 03 Oct 2003 19:32:48 -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 TAA04111 for ; Fri, 3 Oct 2003 19:32:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5ZPj-0000ff-00 for rddp@ietf.org; Fri, 03 Oct 2003 19:32:47 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1A5ZPi-0000fT-00 for rddp@ietf.org; Fri, 03 Oct 2003 19:32:46 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Fri, 3 Oct 2003 16:32:16 -0700 Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 03 Oct 2003 16:32:15 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 3 Oct 2003 16:32:15 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Oct 2003 16:32:14 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 3 Oct 2003 16:32:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] Connection Startup Date: Fri, 3 Oct 2003 16:32:13 -0700 Message-ID: Thread-Topic: [rddp] Connection Startup thread-index: AcOJ/lERQcdzVx2tR6ulgM2PARvJMgAB/jDA From: "Jim Pinkerton" To: "Caitlin Bestler" Cc: X-OriginalArrivalTime: 03 Oct 2003 23:32:14.0724 (UTC) FILETIME=[93994C40:01C38A06] Content-Transfer-Encoding: quoted-printable 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I'm not sure we're going to converge on this discussion, so I suggest we agree to bury the hatchet, make sure the feature works, mandatory to implement, and optional to use, and move on. Jim > -----Original Message----- > From: Caitlin Bestler [mailto:cait@asomi.com] > Sent: Friday, October 03, 2003 3:34 PM > To: Jim Pinkerton > Cc: rddp@ietf.org > Subject: Re: [rddp] Connection Startup >=20 >=20 > On Friday, October 3, 2003, at 04:48 PM, Jim Pinkerton wrote: >=20 > > The reason I bring this up so strongly is for *new* protocols, which > > are > > designed to run on top of IWARP, and don't care about compatiblity with > > InfiniBand, I see no need for this capability. It's far more optimal to > > embed their config data in their existing configuration handshakes, and > > not add a new round-trip handshake. >=20 > That is a valid concern when adding an RDMA mode to an *existing* > protocol, such as iSCSI. And the number of *existing* protocols > that are LLP neutral is, well, pretty much zero. >=20 > Use of an RDMA negotiation message *after* other negotiations would > indeed be a wasteful additional round-trip. The intent is to support > applications that only need minimal simple parameters exchanges in > order to establish the session. When this topic has been discussed > in the DAT Collaborative, there has been little interest in engaging > in more complex session setup. >=20 > The only thing that *must* be negotiated before enabling RDMA is > the essential RDMA configuration (identifying any existing session, > RDMA read credits, maximum untagged message size, etc.) to the > extent that it is not pre-dictated as constants for that ULP. >=20 > The general conclusion I have seen application developers who > are working on an RDMA specific applications is that complex > detailed negotiations can be done *after* the connection is > established. >=20 > Now you can argue that they were merely thinking that way > because that is the only model that InfiniBand supported. > Or perhaps, that is the only model that InfiniBand > supported because it is a fine model that meets the > needs of ULP designers who are assuming RDMA capability. >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Oct 3 20:09:25 2003 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 UAA04999 for ; Fri, 3 Oct 2003 20:09:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Zyp-0003rU-KH for rddp-archive@odin.ietf.org; Fri, 03 Oct 2003 20:09:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9409351014838 for rddp-archive@odin.ietf.org; Fri, 3 Oct 2003 20:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Zyp-0003rF-En for rddp-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 20:09:03 -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 UAA04994 for ; Fri, 3 Oct 2003 20:08:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Zyn-00010C-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 20:09:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5Zym-000109-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 20:09:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Zyn-0003ql-Ts; Fri, 03 Oct 2003 20:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Zxp-0003ok-BO for rddp@optimus.ietf.org; Fri, 03 Oct 2003 20:08:01 -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 UAA04982 for ; Fri, 3 Oct 2003 20:07:53 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Zxn-0000zs-00 for rddp@ietf.org; Fri, 03 Oct 2003 20:07:59 -0400 Received: from unk-for-smtp.isus.emc.com ([128.222.32.10] helo=mxic1.corp.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1A5Zxm-0000zb-00 for rddp@ietf.org; Fri, 03 Oct 2003 20:07:58 -0400 Received: by mxic1.corp.emc.com with Internet Mail Service (5.5.2653.19) id <4FX8VPVK>; Fri, 3 Oct 2003 20:07:23 -0400 Message-ID: To: rddp@ietf.org Subject: RE: [rddp] Re: Invalidation Date: Fri, 3 Oct 2003 20:07:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , > From reading your email, it sounds like you are thinking there is a > layering violation? Is that your point? No. It appears that invalidation is a rather important mechanism for actually using STags, and so, aside from historical reasons, what's the rationale for it being an RDMAP operation rather than a DDP operation? Another way to ask this is: does absence of STag invalidation from DDP significantly reduce the usefulness of DDP without RDMAP? Alternatively, is invalidation sufficiently ULP (wrt DDP, e.g., RDMAP)-specific that it needs to be left to DDP's ULPs to implement and customize in their own fashion? If yes, the next question will be why it belongs in the RDMAP layer, as opposed to RDMAP providing local access to the DDP interface for STag invalidation, and letting ULPs figure out how to communicate STags when remote invalidation is in order. I don't have a preconceived notion of the answers, but there's some design rationale that needs to be brought out and discussed here. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Oct 3 21:03:24 2003 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 VAA05986 for ; Fri, 3 Oct 2003 21:03:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5ap4-0005RG-Ug for rddp-archive@odin.ietf.org; Fri, 03 Oct 2003 21:03:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h94132O3020900 for rddp-archive@odin.ietf.org; Fri, 3 Oct 2003 21:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5ap4-0005R1-QF for rddp-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 21:03: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 VAA05965 for ; Fri, 3 Oct 2003 21:02:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5ap2-0001LW-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 21:03:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5ap1-0001LT-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 21:02:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5ap3-0005QK-Ds; Fri, 03 Oct 2003 21:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5aoT-0005Ob-DH for rddp@optimus.ietf.org; Fri, 03 Oct 2003 21:02:25 -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 VAA05947 for ; Fri, 3 Oct 2003 21:02:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5aoQ-0001Ky-00 for rddp@ietf.org; Fri, 03 Oct 2003 21:02:22 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 1A5aoQ-0001Ke-00 for rddp@ietf.org; Fri, 03 Oct 2003 21:02:22 -0400 Received: from asomi.com (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 6BCB924579A; Fri, 3 Oct 2003 21:02:23 -0400 (EDT) Date: Fri, 3 Oct 2003 20:02:41 -0500 Subject: Re: [rddp] Re: Invalidation Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: rddp@ietf.org To: Black_David@emc.com From: Caitlin Bestler In-Reply-To: Message-Id: <743E0320-F606-11D7-9D7F-003065D48EE0@asomi.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Friday, October 3, 2003, at 07:07 PM, Black_David@emc.com wrote: >> From reading your email, it sounds like you are thinking there is a >> layering violation? Is that your point? > > No. It appears that invalidation is a rather important mechanism > for actually using STags, and so, aside from historical reasons, what's > the rationale for it being an RDMAP operation rather than a DDP > operation? > > Another way to ask this is: does absence of STag invalidation from DDP > significantly reduce the usefulness of DDP without RDMAP? > Alternatively, > is invalidation sufficiently ULP (wrt DDP, e.g., RDMAP)-specific that > it needs to be left to DDP's ULPs to implement and customize in their > own fashion? > > If yes, the next question will be why it belongs in the RDMAP layer, > as opposed to RDMAP providing local access to the DDP interface for > STag invalidation, and letting ULPs figure out how to > communicate STags when remote invalidation is in order. > > I don't have a preconceived notion of the answers, but there's some > design rationale that needs to be brought out and discussed here. > As currently drafted, the DDP layer merely places the data from valid DDP Segments, notes that the DDP Segment was placed, and optionally notifies the next layer of completions. STag invalidation must take place at or after completion time, not at placement time. Therefore it would be awkward to handle it within the DDP layer. One of the justifications for the layering in my mind is that it allows a very simple state machine to implement the DDP layer, possibly leaving the RDMAP layer to a more complex device (such as a processor). Caitlin Bestler - cait@asomi.com - http://asomi.com/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Oct 3 21:27:23 2003 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 VAA06720 for ; Fri, 3 Oct 2003 21:27: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 1A5bCI-0006PH-72 for rddp-archive@odin.ietf.org; Fri, 03 Oct 2003 21:27:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h941R2hN024621 for rddp-archive@odin.ietf.org; Fri, 3 Oct 2003 21:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5bCI-0006P2-2f for rddp-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 21:27: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 VAA06708 for ; Fri, 3 Oct 2003 21:26:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5bCF-0001dC-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 21:26:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5bCE-0001d9-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 21:26:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5bCG-0006OK-Jo; Fri, 03 Oct 2003 21:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5bBU-0006Nw-NP for rddp@optimus.ietf.org; Fri, 03 Oct 2003 21:26:12 -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 VAA06692 for ; Fri, 3 Oct 2003 21:26:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5bBR-0001cm-00 for rddp@ietf.org; Fri, 03 Oct 2003 21:26:09 -0400 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1A5bBR-0001cJ-00 for rddp@ietf.org; Fri, 03 Oct 2003 21:26:09 -0400 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Oct 2003 18:25:39 -0700 Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 03 Oct 2003 18:25:39 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Oct 2003 18:25:39 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Oct 2003 18:25:38 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 3 Oct 2003 18:25:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] Connection Startup Date: Fri, 3 Oct 2003 18:25:36 -0700 Message-ID: Thread-Topic: [rddp] Connection Startup thread-index: AcOI9a+MeMl/v+2qQxqAsrvFhfCQwgBIAIuA From: "Jim Pinkerton" To: "Caitlin Bestler" Cc: , "David Black" X-OriginalArrivalTime: 04 Oct 2003 01:25:38.0058 (UTC) FILETIME=[6AB3AEA0:01C38A16] Content-Transfer-Encoding: quoted-printable 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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 >=20 >=20 > On Wednesday, October 1, 2003, at 10:36 PM, Jim Pinkerton wrote: >=20 > > > > 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). > > >=20 > Yes, the intent is to carry opaque messages between the ULP peers > to enable them to select/configure the RDMA endpoints compatibly. >=20 > > 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?". > > >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > > > > > > > Caitlin Bestler - cait@asomi.com - http://asomi.com/ >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Oct 3 21:46:24 2003 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 VAA07073 for ; Fri, 3 Oct 2003 21:46:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5bUh-0007Df-6s for rddp-archive@odin.ietf.org; Fri, 03 Oct 2003 21:46:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h941k38i027745 for rddp-archive@odin.ietf.org; Fri, 3 Oct 2003 21:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5bUh-0007DQ-2o for rddp-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 21:46:03 -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 VAA07067 for ; Fri, 3 Oct 2003 21:45:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5bUe-0001mG-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 21:46:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5bUd-0001mD-00 for rddp-web-archive@ietf.org; Fri, 03 Oct 2003 21:45:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5bUf-0007Cy-AB; Fri, 03 Oct 2003 21:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5bUQ-0007CP-BQ for rddp@optimus.ietf.org; Fri, 03 Oct 2003 21:45:46 -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 VAA07054 for ; Fri, 3 Oct 2003 21:45:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5bUN-0001lv-00 for rddp@ietf.org; Fri, 03 Oct 2003 21:45:43 -0400 Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx with esmtp (Exim 4.12) id 1A5bUM-0001ls-00 for rddp@ietf.org; Fri, 03 Oct 2003 21:45:42 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by palrel10.hp.com (Postfix) with ESMTP id 612111C007A0; Fri, 3 Oct 2003 18:45:43 -0700 (PDT) Received: from swathi (dhcp-roseor-bdj047.rose.hp.com [15.23.139.47]) by rosemail.rose.hp.com with SMTP (8.7.1/8.7.3 SMKit7.02) id SAA01864; Fri, 3 Oct 2003 18:45:42 -0700 (PDT) Message-ID: <005f01c38a19$39a2ec60$2f8b170f@rose.hp.com> From: "Mallikarjun C." To: , References: Subject: Re: [rddp] Re: Invalidation Date: Fri, 3 Oct 2003 18:45:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Since I'm one of the few who advocated this feature for the benefit of ULPs (such as iSER), let me add my comments. > is invalidation sufficiently ULP (wrt DDP, e.g., RDMAP)-specific Yes, I believe so. Ultimately, it is the ULP that decides how long remote access for an STag (app buffer) should be allowed based on application considerations such as an "application transaction" (an example "transaction" for iSCSI/iSER is the exchange of cmd-data-status for one I/O), and the risk in not invalidating. >that > it needs to be left to DDP's ULPs to implement and customize in their > own fashion? > > If yes, the next question will be why it belongs in the RDMAP layer, > as opposed to RDMAP providing local access to the DDP interface for > STag invalidation, and letting ULPs figure out how to > communicate STags when remote invalidation is in order. Today, the RDMAP spec only provides the semantics and wire protocol specifics around invalidation. It is left to the ULPs (of RDMAP) to figure out how to use the protocol feature to achieve the desired results - again they know best when to disallow access to the underlying buffers. Now, a natural follow-up question might be why cannot the ULPs do the invalidation themselves. It appeared to us that it's more efficient to have the auto-invalidation take place in the RDMAP layer, so the ULP can simply sanity-check the invalidated STag value post-fact (that could be part of the completion message delivering the Send Message payload), rather than having to turn around right away and ask the RDMAP/DDP layers to do the invalidation. IOW, one round-trip through the RDMAP/DDP layers (right after processing an inbound Send Message) is eliminated by the auto-invalidation. In a hardware RNIC implementation where the ULP-RDMAP boundary is also the software-hardware boundary, the savings resulting out of eliminating this round trip are much more substantial. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: To: Sent: Friday, October 03, 2003 5:07 PM Subject: RE: [rddp] Re: Invalidation > > From reading your email, it sounds like you are thinking there is a > > layering violation? Is that your point? > > No. It appears that invalidation is a rather important mechanism > for actually using STags, and so, aside from historical reasons, what's > the rationale for it being an RDMAP operation rather than a DDP operation? > > Another way to ask this is: does absence of STag invalidation from DDP > significantly reduce the usefulness of DDP without RDMAP? Alternatively, > is invalidation sufficiently ULP (wrt DDP, e.g., RDMAP)-specific that > it needs to be left to DDP's ULPs to implement and customize in their > own fashion? > > If yes, the next question will be why it belongs in the RDMAP layer, > as opposed to RDMAP providing local access to the DDP interface for > STag invalidation, and letting ULPs figure out how to > communicate STags when remote invalidation is in order. > > I don't have a preconceived notion of the answers, but there's some > design rationale that needs to be brought out and discussed here. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Oct 3 21:49:23 2003 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 ; 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 ; 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 ; 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, 3 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" To: "Jim Pinkerton" Cc: 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C38A19.806DC980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 >>=20 >>=20 >> On Wednesday, October 1, 2003, at 10:36 PM, Jim Pinkerton wrote: >>=20 >> > >> > 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). >> > >>=20 >> Yes, the intent is to carry opaque messages between the ULP peers >> to enable them to select/configure the RDMA endpoints compatibly. >>=20 >> > 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?". >> > >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> > >> > >> > >> Caitlin Bestler - cait@asomi.com - http://asomi.com/ >>=20 > > >_______________________________________________ >rddp mailing list >rddp@ietf.org >https://www1.ietf.org/mailman/listinfo/rddp ------_=_NextPart_001_01C38A19.806DC980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [rddp] Connection Startup

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.or= g/mailman/listinfo/rddp

------_=_NextPart_001_01C38A19.806DC980-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Sat Oct 4 19:39:27 2003 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 TAA18759 for ; Sat, 4 Oct 2003 19:39:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5vzM-0000LW-Lg for rddp-archive@odin.ietf.org; Sat, 04 Oct 2003 19:39:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h94Nd4QV001327 for rddp-archive@odin.ietf.org; Sat, 4 Oct 2003 19:39:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5vzM-0000LK-Eu for rddp-web-archive@optimus.ietf.org; Sat, 04 Oct 2003 19:39:04 -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 TAA18749 for ; Sat, 4 Oct 2003 19:38:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5vzK-0004Fo-00 for rddp-web-archive@ietf.org; Sat, 04 Oct 2003 19:39:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5vzK-0004Fk-00 for rddp-web-archive@ietf.org; Sat, 04 Oct 2003 19:39:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5vzJ-0000Kp-Bu; Sat, 04 Oct 2003 19:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5vz6-0000Kb-S3 for rddp@optimus.ietf.org; Sat, 04 Oct 2003 19:38:48 -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 TAA18741 for ; Sat, 4 Oct 2003 19:38:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5vz3-0004Fb-00 for rddp@ietf.org; Sat, 04 Oct 2003 19:38:45 -0400 Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx with esmtp (Exim 4.12) id 1A5vz3-0004FL-00 for rddp@ietf.org; Sat, 04 Oct 2003 19:38:45 -0400 Received: from cs.uchicago.edu (h005018030f43.ne.client2.attbi.com[24.128.44.103]) by comcast.net (rwcrmhc13) with SMTP id <2003100423381301500cl5ege>; Sat, 4 Oct 2003 23:38:14 +0000 To: rddp@ietf.org Subject: Re: [rddp] Re: Invalidation In-Reply-To: Message from Black_David@emc.com of "Fri, 03 Oct 2003 20:07:20 EDT." References: Date: Sat, 04 Oct 2003 19:38:12 -0400 From: steph Message-Id: 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , > No. It appears that invalidation is a rather important mechanism > for actually using STags, and so, aside from historical reasons, what's > the rationale for it being an RDMAP operation rather than a DDP > operation? Caitlin said it: DDP is only about placement and RDMA is about control. [But, by the time we're done who knows anymore.] Invalidation is an important mechanism for CERTAIN applications. And given that all RDMA-family protocols over the past 10 or so have pretty much done it the same way [cough, gasp, not...], I'm sure we know exactly how to do it. We should commit it irreversably to gates and provide no alternatives. DDP should be a MINIMUM, self-contained placement mechanism. It is a base upon which different RDMA-type protocols can be built. ULPs can also use DDP, but they should not expect to get a `RDMA-lite' semantics. RDMA is whatever fuller placement-based protocol the community wants for current & anticipated ULPs. As the layering line on DDP is pushed down as far as possible, RDMA's service interface picks up the slack. For example, DDP should not be saying anything about how host-side untagged message resources are managed (i.e. ddp_post_recv()). But it does. Oh well. You can build a variety of invalidation mechanisms on top of DDP. These could be built by a DDP-targeted ULP, or by an RDMAP (a `general purpose' DDP ULP). Invalidation mechanisms defined by an RDMAP become a candidates for hardware handling (performance optimization) like write with invalidate. Steph _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Mon Oct 6 19:40:28 2003 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 TAA28254 for ; Mon, 6 Oct 2003 19:40:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6exS-0007YM-7S for rddp-archive@odin.ietf.org; Mon, 06 Oct 2003 19:40:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h96Ne6fZ029020 for rddp-archive@odin.ietf.org; Mon, 6 Oct 2003 19:40:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6exQ-0007Xy-Pt for rddp-web-archive@optimus.ietf.org; Mon, 06 Oct 2003 19:40:04 -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 TAA28246 for ; Mon, 6 Oct 2003 19:39:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6exO-0005mf-00 for rddp-web-archive@ietf.org; Mon, 06 Oct 2003 19:40:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6exO-0005mb-00 for rddp-web-archive@ietf.org; Mon, 06 Oct 2003 19:40:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6exO-0007Xa-UC; Mon, 06 Oct 2003 19:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6ewp-0007WO-Ux for rddp@optimus.ietf.org; Mon, 06 Oct 2003 19:39:27 -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 TAA28238 for ; Mon, 6 Oct 2003 19:39:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6ewo-0005mJ-00 for rddp@ietf.org; Mon, 06 Oct 2003 19:39:26 -0400 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1A6ewn-0005ln-00 for rddp@ietf.org; Mon, 06 Oct 2003 19:39:25 -0400 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 6 Oct 2003 16:38:55 -0700 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 06 Oct 2003 16:38:55 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 6 Oct 2003 16:38:05 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 6 Oct 2003 16:38:05 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 6 Oct 2003 16:38:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Date: Mon, 6 Oct 2003 16:38:01 -0700 Message-ID: Thread-Topic: Fall IETF agenda thread-index: AcOMYuF6pvxiHoWzTBCmoIqiQSXXxQ== From: "Jim Pinkerton" To: X-OriginalArrivalTime: 06 Oct 2003 23:38:05.0653 (UTC) FILETIME=[E4021050:01C38C62] Subject: [rddp] Fall IETF agenda 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38C62.E034369F" ------_=_NextPart_001_01C38C62.E034369F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 I see an agenda has been posted for the Fall IETF. Unfortunately I don't see a spot for RDDP (or IPS for that matter). =20 Any news? =20 =20 Jim =20 =20 =20 ------_=_NextPart_001_01C38C62.E034369F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I see an agenda has been posted for the Fall IETF. Unfortunately I don’t see a spot for RDDP (or IPS for that = matter).

 

Any news?

 

 

Jim

 

 

 

------_=_NextPart_001_01C38C62.E034369F-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Tue Oct 7 13:39:24 2003 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 NAA13091 for ; Tue, 7 Oct 2003 13:39:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6vna-0005WC-L2 for rddp-archive@odin.ietf.org; Tue, 07 Oct 2003 13:39:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97Hd2gF021206 for rddp-archive@odin.ietf.org; Tue, 7 Oct 2003 13:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6vna-0005Vx-HS for rddp-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 13:39: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 NAA13078 for ; Tue, 7 Oct 2003 13:38:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6vnY-0001Dc-00 for rddp-web-archive@ietf.org; Tue, 07 Oct 2003 13:39:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6vnX-0001DZ-00 for rddp-web-archive@ietf.org; Tue, 07 Oct 2003 13:38:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6vnZ-0005Tu-26; Tue, 07 Oct 2003 13:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6vmj-0005Sl-64 for rddp@optimus.ietf.org; Tue, 07 Oct 2003 13:38:09 -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 NAA13057 for ; Tue, 7 Oct 2003 13:38:00 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6vmh-0001D9-00 for rddp@ietf.org; Tue, 07 Oct 2003 13:38:07 -0400 Received: from unk-for-smtp.isus.emc.com ([128.222.32.10] helo=mxic1.corp.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1A6vmg-0001CI-00 for rddp@ietf.org; Tue, 07 Oct 2003 13:38:06 -0400 Received: by mxic1.corp.emc.com with Internet Mail Service (5.5.2653.19) id <43M5GHJ2>; Tue, 7 Oct 2003 13:35:36 -0400 Message-ID: To: jpink@windows.microsoft.com, rddp@ietf.org Subject: RE: [rddp] Fall IETF agenda Date: Tue, 7 Oct 2003 13:21:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38CF7.659CEE20" 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C38CF7.659CEE20 Content-Type: text/plain The meeting request was submitted Wednesday of last week; I suspect there's some lazy evaluation in the scheduling process. Please keep in mind that meeting slots can and do move prior to the agenda being final (i.e., don't assume that the meeting day/time that are initially assigned will be the final ones). Thanks, --David -----Original Message----- From: Jim Pinkerton [mailto:jpink@windows.microsoft.com] Sent: Monday, October 06, 2003 7:38 PM To: rddp@ietf.org Subject: [rddp] Fall IETF agenda I see an agenda has been posted for the Fall IETF. Unfortunately I don't see a spot for RDDP (or IPS for that matter). Any news? Jim ------_=_NextPart_001_01C38CF7.659CEE20 Content-Type: text/html Message
The meeting request was submitted Wednesday of last week; I suspect there's
some lazy evaluation in the scheduling process.  Please keep in mind
that meeting slots can and do move prior to the agenda being final
(i.e., don't assume that the meeting day/time that are initially assigned
will be the final ones).
 
Thanks,
--David
-----Original Message-----
From: Jim Pinkerton [mailto:jpink@windows.microsoft.com]
Sent: Monday, October 06, 2003 7:38 PM
To: rddp@ietf.org
Subject: [rddp] Fall IETF agenda

 

I see an agenda has been posted for the Fall IETF. Unfortunately I don't see a spot for RDDP (or IPS for that matter).

 

Any news?

 

 

Jim

 

 

 

------_=_NextPart_001_01C38CF7.659CEE20-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Oct 9 15:47:25 2003 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 PAA07239 for ; Thu, 9 Oct 2003 15:47:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7gkZ-0003Ra-7k for rddp-archive@odin.ietf.org; Thu, 09 Oct 2003 15:47:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99Jl3Bj013234 for rddp-archive@odin.ietf.org; Thu, 9 Oct 2003 15:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7gkZ-0003RE-3L for rddp-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 15:47:03 -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 PAA07172 for ; Thu, 9 Oct 2003 15:46:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7gkX-0003Ra-00 for rddp-web-archive@ietf.org; Thu, 09 Oct 2003 15:47:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7gkX-0003RU-00 for rddp-web-archive@ietf.org; Thu, 09 Oct 2003 15:47:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7gkW-0003Q1-Fr; Thu, 09 Oct 2003 15:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7gje-0003ME-HF for rddp@optimus.ietf.org; Thu, 09 Oct 2003 15:46:06 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07078; Thu, 9 Oct 2003 15:45:57 -0400 (EDT) Message-Id: <200310091945.PAA07078@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rddp@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 09 Oct 2003 15:45:57 -0400 Subject: [rddp] I-D ACTION:draft-ietf-rddp-mpa-00.txt 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Direct Data Placement Working Group of the IETF. Title : Marker PDU Aligned Framing for TCP Specification Author(s) : P. Culley, et. al. Filename : draft-ietf-rddp-mpa-00.txt Pages : 58 Date : 2003-10-9 A framing protocol is defined for TCP that is fully compliant with applicable TCP RFCs and fully interoperable with existing TCP implementations. The framing mechanism is designed to work as an 'adaptation layer' between TCP and the Direct Data Placement [DDP] protocol, preserving the reliable, in-order delivery of TCP, while adding the preservation of higher-level protocol record boundaries that DDP requires. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rddp-mpa-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rddp-mpa-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rddp-mpa-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-9142609.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rddp-mpa-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rddp-mpa-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-9142609.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Sat Oct 11 18:51:24 2003 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 SAA16439 for ; Sat, 11 Oct 2003 18:51:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8SZl-0000ZU-NK for rddp-archive@odin.ietf.org; Sat, 11 Oct 2003 18:51:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9BMp5IB002186 for rddp-archive@odin.ietf.org; Sat, 11 Oct 2003 18:51:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8SZl-0000Z2-HW for rddp-web-archive@optimus.ietf.org; Sat, 11 Oct 2003 18:51:05 -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 SAA16426 for ; Sat, 11 Oct 2003 18:50:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8SZi-0000jx-00 for rddp-web-archive@ietf.org; Sat, 11 Oct 2003 18:51:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8SZh-0000jp-00 for rddp-web-archive@ietf.org; Sat, 11 Oct 2003 18:51:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8SZi-0000Y9-BU; Sat, 11 Oct 2003 18:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8SYw-0000XO-GW for rddp@optimus.ietf.org; Sat, 11 Oct 2003 18:50:14 -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 SAA16402 for ; Sat, 11 Oct 2003 18:50:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8SYt-0000jP-00 for rddp@ietf.org; Sat, 11 Oct 2003 18:50:11 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 1A8SYs-0000iv-00 for rddp@ietf.org; Sat, 11 Oct 2003 18:50:10 -0400 Received: from asomi.com (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id A2605244A59 for ; Sat, 11 Oct 2003 18:50:14 -0400 (EDT) Date: Sat, 11 Oct 2003 17:49:32 -0500 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Caitlin Bestler To: rddp@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <2E1BBE1E-FC3D-11D7-9D1F-000393814604@asomi.com> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [rddp] re: mpa-00 draft - minutae 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Changed Active/Passive nomenclature to Initiator/Responder to > reduce confusion with TCP startup and verbs doc (which used > opposite sense). a) The citation is not reffed here. b) The citation should be to the RDMAC document, as that the specified draft has expired and has not been adopted as a WG document. > MPA includes a CRC check to increase the ULPDU data integrity to the > level provided by other modern protocols, such as SCTP [RFC2960]. Actually, SCTP's CRC checksum is defined in RFC3309 > While the maximum theoretical length supported by the MPA header > ULPDU_Length field is 65535, TCP over IP requires the IP datagram > maximum length to be 65535 octets. To enable MPA to support FPDU > Alignment, the maximum size of the FPDU must fit within an IP > datagram. Thus the ULPDU limit of 64768 octets was derived by taking > the maximum IP datagram length, subtracting from it the maximum total > length of the sum of the IPv4 header, TCP header, IPv4 options, TCP > options, and the worst case MPA overhead, and then rounding the > result down to a 128 octet boundary. MPA should be valid over IPv6 and IPV4 (although obviously a given implementation would be IPv4 and/or IPv6). Therefore it should be made clear that you might have to subtract the length of an IPv6 header. A totally cautious application should allow for IPv6 or IPv4. -------------------------- Caitlin Bestler - http://asomi.com/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Sat Oct 11 19:41:15 2003 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 SAA16438 for ; Sat, 11 Oct 2003 18:51:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8SZl-0000ZJ-LK for rddp-archive@odin.ietf.org; Sat, 11 Oct 2003 18:51:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9BMp5tC002173 for rddp-archive@odin.ietf.org; Sat, 11 Oct 2003 18:51:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8SZl-0000Yx-DM for rddp-web-archive@optimus.ietf.org; Sat, 11 Oct 2003 18:51:05 -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 SAA16424 for ; Sat, 11 Oct 2003 18:50:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8SZi-0000ju-00 for rddp-web-archive@ietf.org; Sat, 11 Oct 2003 18:51:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8SZh-0000jo-00 for rddp-web-archive@ietf.org; Sat, 11 Oct 2003 18:51:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8SZh-0000Xt-PC; Sat, 11 Oct 2003 18:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8SYn-0000XD-E9 for rddp@optimus.ietf.org; Sat, 11 Oct 2003 18:50:05 -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 SAA16392 for ; Sat, 11 Oct 2003 18:49:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8SYk-0000j9-00 for rddp@ietf.org; Sat, 11 Oct 2003 18:50:02 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 1A8SYj-0000is-00 for rddp@ietf.org; Sat, 11 Oct 2003 18:50:01 -0400 Received: from asomi.com (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id C03EF2449B1 for ; Sat, 11 Oct 2003 18:49:57 -0400 (EDT) Date: Sat, 11 Oct 2003 17:49:17 -0500 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Caitlin Bestler To: rddp@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <24DF3EE8-FC3D-11D7-9D1F-000393814604@asomi.com> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [rddp] re: mpa-00 draft - 8.1 Connection Setup 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Note: The requirement to wait on a Request Frame before sending a > Reply frame is a design choice, it makes for well ordered > sequence of events at each end, and avoids having to specify > how to deal with situations where both ends start at the same > time. As covered in the SCTP draft, supporting Active/Active startup is not that difficult. Admittedly, it is not that useful, either. All that is required is to define a third value for "instant start", which each side sends *and* expects to receive. For the goal of LLP neutrality, I believe that this should be added to the MPA draft, or removed from the SCTP mapping. I'm neutral on the topic, and would love to hear other opinions. The strongest argument for inclusion is that it is simple. The strongest argument for exclusion is that even simple things must go through QA. > Note: Since the receiver's ability to deal with markers is > unknown until the Request and Reply frames have been > received, sending FPDUs before this occurs is not possible. If a mismatch in capabilities will result in terminating the connection, then there is nothing wrong with sending FPDUs before this is confirmed. If there is a mismatch, the FPDUs will be flushed anyway. Obviously traffic should not be placed on the network that has any substantial chance of being thrown away. But if the sender has reason to believe that it already knows its peers mode (perhaps based on directory information or prior connections) then it should not be required to stall waiting for dynamic confirmation. > 4. MPA "Responder" mode implementations MUST receive and validate at > least one FPDU before sending any FPDUs or markers. > > > Note: this requirement is present to allow the Initiator time to > get its receiver into full operation before an FPDU arrives, > avoiding potentially difficult requirements on the receiver. As previously covered, I believe this rule is overly broad. The only requirement is that neither side send their MPA Start Frame before they are ready to process DDP Segments. > 6. The received "Private Data" fields may be used by consumers at > either end to further validate the connection, and set up DDP or > other ULP parameters. The ULP MAY close the TCP/MPA/DDP > connection as a result of validating the "Private Data" fields. If the ULP "may" use the Private Data, then the stack MUST pass the Private Data to the ULP. I believe that this would be better stated explicitly. > 8. MPA implementations MUST use the difference between the MPA > Request Frame and the MPA Reply Frame to check for incorrect > "Initiator/Initiator" startups. Implementations SHOULD put a > timeout on waiting for the MPA Reply Frame when started in > "Responder" mode, to detect incorrect "Responder/Responder" > startups. Which might imply that the Hamming Distance between the two frames perhaps should be a bit larger than a few bits, especially since the field only has TCP protection. > (Dual-Stack) Note: Regardless of the "stack" architecture used, TCP's > rules must be followed. For example, if network data is lost, re-segmented > or re-ordered, TCP must recover appropriately even when this > occurs while switching stacks. It should be noted that the same remote host may be serviced by *both* of these stacks. Therefore L2/L3 messages that relate to a remote IP address may have to be processed by *both* stacks. ----------------------------------------------- Caitlin Bestler - http://asomi.com/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Tue Oct 14 09:11:25 2003 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 JAA08001 for ; Tue, 14 Oct 2003 09:11:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Ox6-00059L-N6 for rddp-archive@odin.ietf.org; Tue, 14 Oct 2003 09:11:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EDB4Yv019789 for rddp-archive@odin.ietf.org; Tue, 14 Oct 2003 09:11:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Ox6-000596-HJ for rddp-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 09:11:04 -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 JAA07977 for ; Tue, 14 Oct 2003 09:10:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Ox4-0002IS-00 for rddp-web-archive@ietf.org; Tue, 14 Oct 2003 09:11:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9Ox4-0002IO-00 for rddp-web-archive@ietf.org; Tue, 14 Oct 2003 09:11:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Ox3-00058Y-KB; Tue, 14 Oct 2003 09:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Ox0-00056w-Vx for rddp@optimus.ietf.org; Tue, 14 Oct 2003 09:10:58 -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 JAA07972 for ; Tue, 14 Oct 2003 09:10:49 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Owz-0002IL-00 for rddp@ietf.org; Tue, 14 Oct 2003 09:10:57 -0400 Received: from unk-for-smtp.isus.emc.com ([128.222.32.10] helo=mxic1.corp.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1A9Owz-0002Hh-00 for rddp@ietf.org; Tue, 14 Oct 2003 09:10:57 -0400 Received: by mxic1.corp.emc.com with Internet Mail Service (5.5.2653.19) id <4468PANX>; Tue, 14 Oct 2003 09:10:20 -0400 Message-ID: To: rddp@ietf.org Date: Tue, 14 Oct 2003 09:10:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [rddp] Tentative rddp meeting time in Minneapolis 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , The current scheduled rddp WG meeting time in Minneapolis is: Tuesday, 11 November at 0900-1130 Other groups currently scheduled at that time are: calsch, simple, ipv6, psamp, mpls and sipping. This should appear on the Minneapolis agenda on the IETF web site sometime soon. Please keep in mind that this is subject to change until the Minneapolis agenda is final, which should happen in the latter half of the last week of October. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Wed Oct 15 15:35:27 2003 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 PAA18731 for ; Wed, 15 Oct 2003 15:35:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9rQG-0004kv-MP for rddp-archive@odin.ietf.org; Wed, 15 Oct 2003 15:35:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FJZ4LA018275 for rddp-archive@odin.ietf.org; Wed, 15 Oct 2003 15:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9rQG-0004kg-Gr for rddp-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 15:35:04 -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 PAA18706 for ; Wed, 15 Oct 2003 15:34:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9rQE-0002Bx-00 for rddp-web-archive@ietf.org; Wed, 15 Oct 2003 15:35:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9rQD-0002Bn-00 for rddp-web-archive@ietf.org; Wed, 15 Oct 2003 15:35:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9rQD-0004gh-FS; Wed, 15 Oct 2003 15:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9rPG-0004UT-G0 for rddp@optimus.ietf.org; Wed, 15 Oct 2003 15:34:02 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18558; Wed, 15 Oct 2003 15:33:52 -0400 (EDT) Message-Id: <200310151933.PAA18558@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rddp@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 15 Oct 2003 15:33:52 -0400 Subject: [rddp] I-D ACTION:draft-ietf-rddp-applicability-01.txt 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Direct Data Placement Working Group of the IETF. Title : Applicability of Remote Direct Memory Access Protocol (RDMA)and Direct Data Placement (DDP) Author(s) : C. Bestler, L. Coene Filename : draft-ietf-rddp-applicability-01.txt Pages : 24 Date : 2003-10-15 This document describes the applicability of Remote Direct Memory Access Protocol (RDMAP) and the Direct Data Placement Protocol (DDP). It contrasts the different transport options over IP that DDP can use, compares use of DDP with direct use of the supporting transports, and compares DDP over IP transports with non-IP transports that support RDMA functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rddp-applicability-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rddp-applicability-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rddp-applicability-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-15142703.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rddp-applicability-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rddp-applicability-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-15142703.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Oct 23 09:59:33 2003 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 JAA21797 for ; Thu, 23 Oct 2003 09:59:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACfze-0006q8-D2 for rddp-archive@odin.ietf.org; Thu, 23 Oct 2003 09:59:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NDxEi2026288 for rddp-archive@odin.ietf.org; Thu, 23 Oct 2003 09:59:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACfze-0006pv-9Y for rddp-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 09:59:14 -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 JAA21738 for ; Thu, 23 Oct 2003 09:59:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACfzc-0000NP-00 for rddp-web-archive@ietf.org; Thu, 23 Oct 2003 09:59:12 -0400 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1ACfsS-0000Be-00 for rddp-web-archive@ietf.org; Thu, 23 Oct 2003 09:51:48 -0400 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1ACfm6-00004u-2a for rddp-web-archive@ietf.org; Thu, 23 Oct 2003 09:45:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACflt-0004QN-Cy; Thu, 23 Oct 2003 09:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACfll-0004Ox-QQ for rddp@optimus.ietf.org; Thu, 23 Oct 2003 09:44:53 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20457; Thu, 23 Oct 2003 09:44:42 -0400 (EDT) Message-Id: <200310231344.JAA20457@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rddp@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 23 Oct 2003 09:44:42 -0400 Subject: [rddp] I-D ACTION:draft-ietf-rddp-security-00.txt 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Direct Data Placement Working Group of the IETF. Title : DDP/RDMAP Security Author(s) : J. Pinkerton Filename : draft-ietf-rddp-security-00.txt Pages : 43 Date : 2003-10-22 This document analyzes security issues around implementation and use of the Direct Data Placement Protocol(DDP) and Remote Direct Memory Access Protocol (RDMAP). It first defines an architectural model for an RDMA Network Interface Card (RNIC), which can implement DDP or RDMAP and DDP. The model includes a definition of resources that can be attacked. This document then introduces various Trust Models between a local peer and a remote peer and the tools that can be used to create countermeasures against attacks. Finally, the document reviews various attacks and the countermeasures to be used against them, grouping the attacks into spoofing, tampering, information disclosure, denial of service, and elevation of privilege. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rddp-security-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rddp-security-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rddp-security-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-22184722.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rddp-security-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rddp-security-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-22184722.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Oct 24 09:34:26 2003 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 JAA00073 for ; Fri, 24 Oct 2003 09:34:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD24s-0002UJ-Nj for rddp-archive@odin.ietf.org; Fri, 24 Oct 2003 09:34:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ODY6Uk009557 for rddp-archive@odin.ietf.org; Fri, 24 Oct 2003 09:34:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD24s-0002U4-Jb for rddp-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 09:34:06 -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 JAA00059 for ; Fri, 24 Oct 2003 09:33:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD24q-0003Me-00 for rddp-web-archive@ietf.org; Fri, 24 Oct 2003 09:34:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD24q-0003Mb-00 for rddp-web-archive@ietf.org; Fri, 24 Oct 2003 09:34:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD24m-0002RZ-JE; Fri, 24 Oct 2003 09:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD24a-0002Le-Rh for rddp@optimus.ietf.org; Fri, 24 Oct 2003 09:33:48 -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 JAA00048 for ; Fri, 24 Oct 2003 09:33:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD24Y-0003MS-00 for rddp@ietf.org; Fri, 24 Oct 2003 09:33:47 -0400 Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx with esmtp (Exim 4.12) id 1AD24Y-0003M8-00 for rddp@ietf.org; Fri, 24 Oct 2003 09:33:46 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id h9ODXEIw394140; Fri, 24 Oct 2003 09:33:14 -0400 Received: from d03nm130.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9ODXD0g304036; Fri, 24 Oct 2003 07:33:13 -0600 Subject: Re: [rddp] Re: Invalidation To: Black_David@emc.com Cc: rddp@ietf.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Renato Recio Date: Thu, 23 Oct 2003 18:43:22 -0500 X-MIMETrack: Serialize by Router on D03NM130/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 10/24/2003 07:33:13 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , I agree with Mallikarjun's comments below. I also agree with Caitlin's earlier comments. Leaving the invalidation function in the RDMAP layer allows the DDP layer to perform placement and gives the RDMAP layer flexibility regarding how the invalidation function is implemented. The current layering, even allows the DDP layer to be implemented on an adapter and the RDMAP layer on the host OS. Though that type of implementation may be inefficient (compared to others), it may be easier to implement and is possible with the current layering. Thanks, Renato J Recio Chief Architect, eServer I/O IBM Distinguished Engineer Member IBM Academy of Technology Tel 512-838-3685, T/L 678-3685 "Mallikarjun C." To: , Sent by: cc: rddp-admin@ietf.o Subject: Re: [rddp] Re: Invalidation rg 10/03/2003 08:45 PM Since I'm one of the few who advocated this feature for the benefit of ULPs (such as iSER), let me add my comments. > is invalidation sufficiently ULP (wrt DDP, e.g., RDMAP)-specific Yes, I believe so. Ultimately, it is the ULP that decides how long remote access for an STag (app buffer) should be allowed based on application considerations such as an "application transaction" (an example "transaction" for iSCSI/iSER is the exchange of cmd-data-status for one I/O), and the risk in not invalidating. >that > it needs to be left to DDP's ULPs to implement and customize in their > own fashion? > > If yes, the next question will be why it belongs in the RDMAP layer, > as opposed to RDMAP providing local access to the DDP interface for > STag invalidation, and letting ULPs figure out how to > communicate STags when remote invalidation is in order. Today, the RDMAP spec only provides the semantics and wire protocol specifics around invalidation. It is left to the ULPs (of RDMAP) to figure out how to use the protocol feature to achieve the desired results - again they know best when to disallow access to the underlying buffers. Now, a natural follow-up question might be why cannot the ULPs do the invalidation themselves. It appeared to us that it's more efficient to have the auto-invalidation take place in the RDMAP layer, so the ULP can simply sanity-check the invalidated STag value post-fact (that could be part of the completion message delivering the Send Message payload), rather than having to turn around right away and ask the RDMAP/DDP layers to do the invalidation. IOW, one round-trip through the RDMAP/DDP layers (right after processing an inbound Send Message) is eliminated by the auto-invalidation. In a hardware RNIC implementation where the ULP-RDMAP boundary is also the software-hardware boundary, the savings resulting out of eliminating this round trip are much more substantial. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: To: Sent: Friday, October 03, 2003 5:07 PM Subject: RE: [rddp] Re: Invalidation > > From reading your email, it sounds like you are thinking there is a > > layering violation? Is that your point? > > No. It appears that invalidation is a rather important mechanism > for actually using STags, and so, aside from historical reasons, what's > the rationale for it being an RDMAP operation rather than a DDP operation? > > Another way to ask this is: does absence of STag invalidation from DDP > significantly reduce the usefulness of DDP without RDMAP? Alternatively, > is invalidation sufficiently ULP (wrt DDP, e.g., RDMAP)-specific that > it needs to be left to DDP's ULPs to implement and customize in their > own fashion? > > If yes, the next question will be why it belongs in the RDMAP layer, > as opposed to RDMAP providing local access to the DDP interface for > STag invalidation, and letting ULPs figure out how to > communicate STags when remote invalidation is in order. > > I don't have a preconceived notion of the answers, but there's some > design rationale that needs to be brought out and discussed here. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Oct 24 15:02:26 2003 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 PAA23236 for ; Fri, 24 Oct 2003 15:02:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD7CJ-0001rV-0N for rddp-archive@odin.ietf.org; Fri, 24 Oct 2003 15:02:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OJ26tI007154 for rddp-archive@odin.ietf.org; Fri, 24 Oct 2003 15:02:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD7CI-0001rJ-P8 for rddp-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 15:02:06 -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 PAA23209 for ; Fri, 24 Oct 2003 15:01:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD7CF-0002jC-00 for rddp-web-archive@ietf.org; Fri, 24 Oct 2003 15:02:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD7CF-0002j8-00 for rddp-web-archive@ietf.org; Fri, 24 Oct 2003 15:02:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD7CE-0001pq-95; Fri, 24 Oct 2003 15:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD7BX-0001lt-8G for rddp@optimus.ietf.org; Fri, 24 Oct 2003 15:01:19 -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 PAA23178; Fri, 24 Oct 2003 15:01:06 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD7BS-0002iY-00; Fri, 24 Oct 2003 15:01:14 -0400 Received: from [168.159.2.31] (helo=MXIC3.corp.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1AD7BS-0002iV-00; Fri, 24 Oct 2003 15:01:14 -0400 Received: by mxic3.corp.emc.com with Internet Mail Service (5.5.2657.72) id ; Fri, 24 Oct 2003 15:01:12 -0400 Message-ID: To: ips@ietf.org, rddp@ietf.org Date: Fri, 24 Oct 2003 15:01:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [rddp] iSCSI over RDMA (iSER and DA) Internet Drafts 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , On the IPS list, Mallikarjun asked: > Could you please recommend the most optimal course > of action to request and enhance the WG charter? IETF being IETF, the world of "rough consensus and running code", I have no idea what "the most optimal course of action" would be, or whether it even exists :-). The scope of an IETF WG's activities and the items on which it works are managed by the Area Directors and the IESG via the WG's charter, among other means. My understanding of the Transport ADs' views is that the IP Storage WG has been very successful in what the WG set out to do, and the time has come to finish up the current work, declare victory and move on (with the WG either going dormant or being concluded). Of course the ADs always reserve the right to change their minds based on new information, etc., and my understanding may be less than perfect. The people advocating addition of work on iSCSI over RDMA seem to be spending a lot of energy on where the work should be done (process) and much less on whether and why it should be done (technical merits). In my experience, these two topics are best pursued in the opposite order. Specifically, the first decision (ADs and IESG as appropriate) should be whether the work is to be done and with what scope; if that is decided in the affirmative, then matters of where and how can then be worked out in a reasonable fashion. Given this, I do have some advice to offer: (1) A promising path towards undertaking iSCSI over RDMA work in the IETF involves a BOF, e.g., in Seoul. Those interested in such a BOF should approach the Transport Area Directors about organizing and holding one (but first read the material on BOFs in RFC 2418). By the time of the Seoul meeting week, the rddp WG should be done or close to done with most of the drafts on which iSCSI over RDMA depends, providing a firmer foundation for the proposed work. - One of the things that inclines ADs and the IESG towards approval of work is the existence of an open community of people interested in the work, the broader the better. IETF meeting weeks are a good opportunity to solicit interest in possible work towards forming/broadening such a community (e.g., hallway discussion). In furtherance of this, in my role as RDDP WG chair I have already promised the iSER/DA draft authors a 5 minute slot in the RDDP WG meeting in Minneapolis to briefly describe what the drafts are about and solicit interest in working on them (e.g., organize an informal meeting [aka "bar BOF"] to discuss further). For those who are new to this topic, the iSER and DA drafts on the topic of iSCSI over RDMA are: http://www.ietf.org/internet-drafts/draft-ko-iwarp-iser-00.txt http://www.ietf.org/internet-drafts/draft-chadalapaka-iwarp-da-00.txt Thanks, --David (IPS WG co-chair, RDDP WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Tue Oct 28 09:32:23 2003 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 JAA23782 for ; Tue, 28 Oct 2003 09:32:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUtA-0003fw-DX for rddp-archive@odin.ietf.org; Tue, 28 Oct 2003 09:32:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SEW4WT014122 for rddp-archive@odin.ietf.org; Tue, 28 Oct 2003 09:32:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUtA-0003fh-9w for rddp-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 09:32:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23657 for ; Tue, 28 Oct 2003 09:31:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEUt8-0003rW-00 for rddp-web-archive@ietf.org; Tue, 28 Oct 2003 09:32:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEUt8-0003rO-00 for rddp-web-archive@ietf.org; Tue, 28 Oct 2003 09:32:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUt7-0003do-DK; Tue, 28 Oct 2003 09:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUsm-0003bW-6t for rddp@optimus.ietf.org; Tue, 28 Oct 2003 09:31:40 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23583; Tue, 28 Oct 2003 09:31:28 -0500 (EST) Message-Id: <200310281431.JAA23583@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rddp@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 28 Oct 2003 09:31:27 -0500 Subject: [rddp] I-D ACTION:draft-ietf-rddp-rdmap-01.txt 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Direct Data Placement Working Group of the IETF. Title : An RDMA Protocol Specification Author(s) : R. Recio Filename : draft-ietf-rddp-rdmap-01.txt Pages : 66 Date : 2003-10-27 This document defines a Remote Direct Memory Access Protocol (RDMAP) that operates over the Direct Data Placement Protocol (DDP protocol). RDMAP provides read and write services directly to applications and enables data to be transferred directly into ULP Buffers without intermediate data copies. It also enables a kernel bypass implementation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rddp-rdmap-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rddp-rdmap-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rddp-rdmap-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28095134.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rddp-rdmap-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rddp-rdmap-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28095134.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Tue Oct 28 09:32:26 2003 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 JAA23813 for ; Tue, 28 Oct 2003 09:32:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUtA-0003gE-Le for rddp-archive@odin.ietf.org; Tue, 28 Oct 2003 09:32:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SEW4YU014140 for rddp-archive@odin.ietf.org; Tue, 28 Oct 2003 09:32:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUtA-0003fx-Fi for rddp-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 09:32:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23660 for ; Tue, 28 Oct 2003 09:31:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEUt8-0003rZ-00 for rddp-web-archive@ietf.org; Tue, 28 Oct 2003 09:32:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEUt8-0003rP-00 for rddp-web-archive@ietf.org; Tue, 28 Oct 2003 09:32:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUt7-0003dw-NS; Tue, 28 Oct 2003 09:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUst-0003ci-0N for rddp@optimus.ietf.org; Tue, 28 Oct 2003 09:31:47 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23600; Tue, 28 Oct 2003 09:31:34 -0500 (EST) Message-Id: <200310281431.JAA23600@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rddp@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 28 Oct 2003 09:31:34 -0500 Subject: [rddp] I-D ACTION:draft-ietf-rddp-ddp-01.txt,.pdf 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Direct Data Placement Working Group of the IETF. Title : Direct Data Placement over Reliable Transports Author(s) : H. Shah Filename : draft-ietf-rddp-ddp-01.txt,.pdf Pages : 36 Date : 2003-10-27 The Direct Data Placement protocol provides information to Place the incoming data directly into an upper layer protocol's receive buffer without intermediate buffers. This removes excess CPU and memory utilization associated with transferring data through the intermediate buffers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rddp-ddp-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rddp-ddp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rddp-ddp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28095147.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rddp-ddp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rddp-ddp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28095147.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Oct 30 18:57:24 2003 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 SAA21240 for ; Thu, 30 Oct 2003 18:57:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFMf4-0004BG-PW for rddp-archive@odin.ietf.org; Thu, 30 Oct 2003 18:57:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UNv6ok016069 for rddp-archive@odin.ietf.org; Thu, 30 Oct 2003 18:57:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFMf4-0004B5-A5 for rddp-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 18:57:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21211 for ; Thu, 30 Oct 2003 18:56:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFMf0-00052C-00 for rddp-web-archive@ietf.org; Thu, 30 Oct 2003 18:57:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFMf0-000528-00 for rddp-web-archive@ietf.org; Thu, 30 Oct 2003 18:57:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFMey-00049a-Mh; Thu, 30 Oct 2003 18:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFMeG-0003yz-9x for rddp@optimus.ietf.org; Thu, 30 Oct 2003 18:56:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21164 for ; Thu, 30 Oct 2003 18:56:03 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFMeC-00050b-00 for rddp@ietf.org; Thu, 30 Oct 2003 18:56:12 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AFMeC-00050T-01 for rddp@ietf.org; Thu, 30 Oct 2003 18:56:12 -0500 Received: from maho3msx2.isus.emc.com ([128.221.11.32] helo=MAHO3MSX2.corp.emc.com) by manatick with esmtp (Exim 4.24) id 1AFMbx-0005LW-9V for rddp@ietf.org; Thu, 30 Oct 2003 18:53:53 -0500 Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Oct 2003 18:48:37 -0500 Message-ID: To: rddp@ietf.org Date: Thu, 30 Oct 2003 18:48:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [rddp] Status of drafts 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , Here is what your WG chair thinks the status of the RDDP WG's drafts are going into the Minneapolis meeting. Let me know if you think I got anything wrong. Thanks, --David IETF RDDP WG Draft Status - November 2003, Minneapolis IETF meetings -------------------------------------------------------------------- -- Problem Statement and Architecture draft-ietf-rddp-problem-statement-02.txt draft-ietf-rddp-arch-03.txt To become Informational RFCs. Finished WG Last Call, and have been reviewed by our Area Director. Minor changes are needed to respond to the Area Director's comments before going to IETF Last Call. -- Main Protocols DDP (draft-ietf-rddp-ddp-01.txt) RDMAP (draft-ietf-rddp-rdmap-01.txt) To become Proposed Standard RFCs. No technical issues meriting substantial meeting time, but drafts probably have not received extensive technical attention due to WG focus on TCP mapping issues. PLEASE REVIEW THESE DRAFTS!! -- Applicability Statement draft-ietf-rddp-applicability-01.txt To become an Informational RFC. On agenda for this meeting. Please review carefully; alignment of this draft with both the SCTP and TCP mapping drafts is important. -- SCTP Mapping draft-ietf-rddp-sctp-00.txt To become a Proposed Standard RFC. Despite the -00 version number, this is the fourth version of this draft, and it is relatively mature. -- TCP Mapping draft-ietf-rddp-mpa-00.txt To become a Proposed Standard RFC. The major open issues in this draft as of the Vienna meeting involved connection initiation/startup. Substantial meeting time allocated to make progress on these issues. -- Security draft-ietf-rddp-security-00.txt Whether this will be Informational vs. Proposed Standard is TBD. This draft is on the critical path to completing the DDP and RDMAP drafts. Substantial meeting time has been allocated to it. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Oct 30 19:23:21 2003 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 TAA22091 for ; Thu, 30 Oct 2003 19:23:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFN4A-0007A4-2D for rddp-archive@odin.ietf.org; Thu, 30 Oct 2003 19:23:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9V0N20l027522 for rddp-archive@odin.ietf.org; Thu, 30 Oct 2003 19:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFN49-00079p-VD for rddp-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 19:23:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22066 for ; Thu, 30 Oct 2003 19:22:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFN48-0005QW-00 for rddp-web-archive@ietf.org; Thu, 30 Oct 2003 19:23:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFN47-0005QT-00 for rddp-web-archive@ietf.org; Thu, 30 Oct 2003 19:22:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFN48-00078m-Sc; Thu, 30 Oct 2003 19:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFN3L-00075i-9y for rddp@optimus.ietf.org; Thu, 30 Oct 2003 19:22:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22049 for ; Thu, 30 Oct 2003 19:22:00 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFN3J-0005Q5-00 for rddp@ietf.org; Thu, 30 Oct 2003 19:22:09 -0500 Received: from [168.159.2.31] (helo=MXIC3.corp.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1AFN3J-0005Q1-00 for rddp@ietf.org; Thu, 30 Oct 2003 19:22:09 -0500 Received: by mxic3.corp.emc.com with Internet Mail Service (5.5.2657.72) id ; Thu, 30 Oct 2003 19:22:06 -0500 Message-ID: To: rddp@ietf.org Date: Thu, 30 Oct 2003 19:22:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [rddp] DRAFT Minneapolis agenda 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-Subscribe: , I apologize for being a bit late in getting to this, but here's a draft agenda for the Minneapolis RDDP WG meeting. I have a couple of requests: - If your draft is not listed here and you want meeting time, please send me email with the draft name and explanation of why you want meeting time ASAP. - The time slots are intelligent guesses on my part. The two most important technical issues facing the RDDP WG are (in priority order): - Security. A very good security draft is a prerequisite to sending the DDP and RDMAP drafts to the ADs/IESG. - MPA connection startup over TCP. This was a problem in Vienna and has received substantial attention. The time allocations reflect these priorities. If anyone wants more time (e.g., substantial open issues) or less time (e.g., status update from WG chair is sufficient) for a draft, please let me know ASAP, as the (still bashable) meeting agenda is due to the secretariat early next week. Thanks, --David Minneapolis IETF Meeting November 10-14, 2003 -------------------- Remote Direct Data Placement WG (rddp) CHAIR: David L. Black The RDDP WG works on Remote Direct Data Placement and Remote Direct Memory Access functionality. For more information, please refer to the rddp charter at: http://www.ietf.org/html.charters/rddp-charter.html TUESDAY, November 11, 2003, 0900-1130 ------------------------------------- - Agenda Bashing and Administrivia (5 min) - Blue Sheets - NOTE WELL - Status of drafts (5 min) - Applicability Statement (10 min) (draft-ietf-rddp-applicability-01.txt) Mostly a status update. - DDP and RDMAP drafts (10 min) (draft-ietf-rddp-ddp-01.txt, draft-ietf-rddp-rdmap-01.txt) Mostly a status update. These drafts are close to done and are likely to go to WG Last Call before the end of the year. - SCTP Mapping (5 min) (draft-ietf-rddp-sctp-00.txt) Despite the -00 version number, this is the fourth version of this draft, and it is relatively mature. - TCP mapping (30 min) (draft-ietf-rddp-mpa-00.txt) Newly adopted as a WG draft in Vienna, this draft is also on its fourth major version, but there are open issues in the area of connection initiation/startup. - Security (80 min) (draft-ietf-rddp-security-00.txt) Time allocated reflects the importance of progress on this draft. - iSER/DA drafts (5 min) (draft-ko-iwarp-iser-00.txt, draft-chadalapaka-iwarp-da-00.txt) These two individual submissions concern iSCSI extensions for use of RDMA. The authors would like this work to be pursued by the IETF. This time slot provides for a quick description of what these drafts cover; those interested should follow up with the authors directly (e.g., over lunch). _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp