RE: not every song

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

John,

It is clear your aim is providing a connection to a controller.  I would
hope a standard would support more than this one song you sing and provide
access to devices for reasons already mentioned.  How do you envision
controlling clients?  I wonder about your definition of TCP done right.  It
is also clear you wish to see TCP change, as you have often repeated.  FCP
offers WRITE-DATA and READ-RESPONSE structures if desired.  Once a
reasonable flow control akin to FC Class 3 is added, no structural changes
are required as shown in
http://www.ietf.org/internet-drafts/draft-otis-fc-sctp-ip-01.txt.  To
advocate extensive change, show justification.  Bluster not.

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 9:18 PM
> To: ips@ece.cmu.edu
> Subject: RE:
>
>
> 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
> >
>
>
>