RE: [rddp] Connection Startup

One technical clarification on a comment below. You state:

> Both DAFS and NFS over iWarp match the private data
> approach. iSER is the only protocol proposed which negotiates in
> streaming mode and then shifts to RDMA mode.

I'm still coming up to speed on the NFS proposal, but it looks like it
negotiates in streaming mode, and upgrades the connection into RDMA
Mode. See section 2.5.3 in
http://www.ietf.org/internet-drafts/draft-talpey-nfsv4-rdma-sess-00.txt.

I know at least a one of the NFS over RDMA authors monitors this alias -
is the above statement correct?

Jim

> -----Original Message-----
> From: Caitlin Bestler [mailto:cait@asomi.com]
> Sent: Thursday, October 02, 2003 7:59 AM
> To: Jim Pinkerton
> Cc: rddp@ietf.org; David Black
> Subject: Re: [rddp] Connection Startup
> 
> 
> On Wednesday, October 1, 2003, at 10:36 PM, Jim Pinkerton wrote:
> 
> >
> > I don't see any real harm in an optional negotiation frame, since it
is
> > not required. But I think it is interesting to point out that the
> > example below makes it obvious that any content in the optional
> > negotiation frame is application specific (i.e. we are not
attempting
> > to
> > standardize (nor should we) what the contents of the start frame
are).
> >
> 
> Yes, the intent is to carry opaque messages between the ULP peers
> to enable them to select/configure the RDMA endpoints compatibly.
> 
> > For InfiniBand, there are a bunch of different definitions for the
> > private data contained in the connection setup sequence, and each
one
> > is
> > application dependent. There are a few parameters that are common,
but
> > the reality is little else is (see the InfiniBand spec Appendices at
> > http://infinibandta.org for the details).
> >
> > Thus to me the only rationale for creating the optional negotiation
> > frame is to enable a 3rd party to strip off the application data
from
> > the data stream, and present it through a separate interface to the
> > application. This is what Caitlin outlined below. From my jaded
view,
> > this is essentially "how do you graft software infrastructure that
was
> > created for InfiniBand on top of iWARP?".
> >
> 
> If that were the goal, the "private data" would have included some of
> the standard fields for the CM protocol that are relevant --
especially
> those related to RDMA Read credits.
> 
> I believe a better statement of the goal is to encourage development
> of RDMA-aware transport neutral applications. For IETF purposes the
> critical transport neutrality is between SCTP and TCP.  The next
> draft of the applicability statement will expand on this (it is
> under co-author review now, but if you read the latest SCTP and
> MPA drafts you'll see that transport neutral RDMA connection setup
> is easily achievable). Being compatible with the IT-API,
> the DAT APIs and the InfiniBand CM is just a bonus.
> 
> There are indeed some applications that will be forced to deal with
> both the socket layer and the RDMA interface. But I believe this will
> be the exception. Both DAFS and NFS over iWarp match the private data
> approach. iSER is the only protocol proposed which negotiates in
> streaming mode and then shifts to RDMA mode.
> 
> One of the main benefits of RDMA is that it allows the ULP to work
> at a much higher level of abstraction. A standard exchange of
> messages *before* RDMA endpoints are selected/configured that
> can be done *without* knowing which LLP is in use is totally
> consistent with that goal.
> 
> It also *allows* the negotiation frame to be implemented by
> hardware/firmware/drivers and/or middle-ware. This is also
> a major benefit, because it *can* minimize context switching.
> 
> >
> >
> >
> Caitlin Bestler - cait@asomi.com - http://asomi.com/
> 

_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp