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