RE: 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:[email protected]]
>> Sent: Thursday, October 02, 2003 7:59 AM
>> To: Jim Pinkerton
>> Cc: [email protected]; 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 - [email protected] - http://asomi.com/
>> 
>
>
>_______________________________________________
>rddp mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/rddp