RE:

["John Hufferd/San Jose/IBM" <hufferd@us.ibm.com>]

Douglas,
not every song you sing should have the same tune over and over and over.
We have heard it very well.  In fact I look forward to the point in time
that we will have completed the TCP/IP version of iSCSI and turn our focus
at whether SCTP is approprate and how it will benefit iSCSI.

Now against my better judgement I will try to engage this one more time.  A
careful reading of my note implies nothing like you have read into it.  We
looked at the value of the functions that Costa had in his original
proposal for OPTIONAL extensions to TCP/IP.  When these were used they
permitted, in my estimation and others, a positive effect on a number of
TCP/IP applications.  It just so happened that one of the applications was
iSCSI.

Now, the arguments that I put in my note stated why we chose to move the
TCP/IP RDMA option to the background.  I think this very thread captures
the essence of the reason why it was put on a back burner.  There were also
strong feeling that TCP/IP done right could move us forward in a
significant way even without the RDMA option.  We did not want to sacrifice
the Very Very Good for the Perfect.

If Costa and group can in another reflector and a separate set of
interactions with the IETF (perhaps with our support) get acceptance for
the TCP/IP RDMA option then that would be good for many TCP/IP applications
including iSCSI.  And I, for one wish them good luck.

Since this thread was intended to give Costa my thoughts, which I have,
there is nothing to gain to continue this discussion thread further.

.
.
.
John L. Hufferd



"Douglas Otis" <dotis@sanlight.net> on 09/27/2000 06:50:20 PM

To:   John Hufferd/San Jose/IBM@IBMUS, <ips@ece.cmu.edu>
cc:
Subject:  RE:



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
>