RE: [rddp] Connection Startup

["Jim Pinkerton" <[e-mail]>]

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. 

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. 

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.

 

Jim







> -----Original Message-----
> From: Caitlin Bestler [mailto:[e-mail]]
> Sent: Thursday, October 02, 2003 7:59 AM
> To: Jim Pinkerton
> Cc: [e-mail]; 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 - [e-mail] - http://asomi.com/
> 


_______________________________________________
rddp mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rddp