RE:

["Douglas Otis" <dotis@sanlight.net>]

John,

If the intent of the draft-satran-iscsi-01.txt is to eventually modify TCP
in a significant way, these issues should be addressed ahead of concluding
such features as RDMA with TCP will become available.  As much of the
optimization required in the use of TCP for SCSI hinge on such
modifications, it would appear you have already concluded such modifications
*will* take place.

Most should agree frame alignment, out of sequence processing, independent
streams sharing a single control, and zero-copy data handling are deciding
issues.  Separate TCP buffers to control resources, frame alignment, unique
TCP APIs are between the lines in this proposal.  Before havoc ensues, there
is an alternative.  Rather than bending TCP to fit, SCTP has already laid a
foundation.  As such, *no* transport modifications are required and yet
customers still get friendly TCP behavior.

Doug


> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> John Hufferd/San Jose/IBM
> Sent: Wednesday, September 27, 2000 3:08 PM
> To: ips@ece.cmu.edu
> Subject:
>
>
> Costa,
> If you remember way back when we first got together, you had a good RDMA
> proposal for use with TCP/IP using the various optional fields.  We all
> seemed to love it at the time.  I for one was disappointed when we dropped
> it  out of the iSCSI proposal (even as an optional consideration).  The
> thoughts were, that if we started to push this onto TCP/IP folks, we would
> spend much time on that and not get the iSCSI stuff done. So it was
> dropped.
>
> I for one would find it useful to bring it back, but only as an optional
> feature, and only if that did not get in the way of the iSCSI Stuff, since
> you can see how that has already begin to fill up the current ips
> reflector.  But I think working it as a side issue, on another reflector,
> until it is fully baked seems OK to me.
>
> Summary:
> RDMA  --  Yes -- the one you originally had  proposed
> Optional --Yes
>
> .
> .
> .
> John L. Hufferd
>