RE: Connection Startup

I agree with your conclusion that we both support the capability. 

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:[email protected]]
> Sent: Friday, October 03, 2003 1:38 PM
> To: Jim Pinkerton
> Cc: [email protected]
> Subject: Re: [rddp] Connection Startup
> 
> 
> 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 - [email protected] - http://asomi.com/
>