RE: Data in SCSI Response or SCSI Data

[Black_David@emc.com]

I should point out that TCP's URGENT functionality
may be of some use here -- it won't provide the
level of support for message boundaries found
in SCTP, but might still be quite useful.  --David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
black_david@emc.com  Cellular: +1 (978) 394-7754
---------------------------------------------------


> -----Original Message-----
> From:	Douglas Otis [SMTP:dotis@sanlight.net]
> Sent:	Monday, August 28, 2000 2:25 PM
> To:	julian_satran@il.ibm.com; ips@ece.cmu.edu
> Subject:	RE: Data in SCSI Response or SCSI Data
> 
> Julo,
> 
> RFC 793 (TCP pg 12)
>   "A sending TCP is allowed to collect data from the sending user and to
>   send that data in segments at its own convenience, until the push
>   function is signaled, then it must send all unsent data.  When a
>   receiving TCP sees the PUSH flag, it must not wait for more data from
>   the sending TCP before passing the data to the receiving process.
> 
>   There is no necessary relationship between push functions and segment
>   boundaries.  The data in any particular segment may be the result of a
>   single SEND call, in whole or part, or of multiple SEND calls.
> 
>   The purpose of push function and the PUSH flag is to push data through
>   from the sending user to the receiving user.  It does not provide a
>   record service.
> 
>   There is a coupling between the push function and the use of buffers
>   of data that cross the TCP/user interface.  Each time a PUSH flag is
>   associated with data placed into the receiving user's buffer, the
>   buffer is returned to the user for processing even if the buffer is
>   not filled.  If data arrives that fills the user's buffer before a
>   PUSH is seen, the data is passed to the user in buffer size units."
> 
> It would appear you are assuming a relationship between PUSH flags and
> segment boundaries.  In addition, as iSCSI is the confluence of
> independent
> traffic, at what point would you set the PUSH flag?  You suggest rather
> than
> a push function, there is a last datagram signal according to your
> comments
> below.  Even with a PUSH flag, adding data to the buffer before completion
> of push function does not provide guaranteed segment alignment nor is
> there
> any signaling for completion nor is there any intent at providing the
> alignment function you indicate.  You suggest a 'last datagram' signal
> provides a simple means of positioning information at the beginning of the
> TCP Datagram.  What signal?  In keeping within TCP, how do you implement
> your comments below which you state is the basis of iSCSI.
> 
> Doug
> 
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > julian_satran@il.ibm.com
> > Sent: Monday, August 28, 2000 9:18 AM
> > To: ips@ece.cmu.edu
> > Subject: RE: Data in SCSI Response or SCSI Data
> >
> >
> >
> >
> > Doug,
> >
> > I would appreciate if instead of a general and fuzzy referency you would
> > quote
> > the document page and paragraph.
> >
> > Julo
> >
> > "Douglas Otis" <dotis@sanlight.net> on 28/08/2000 19:00:56
> >
> > Please respond to "Douglas Otis" <dotis@sanlight.net>
> >
> > To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> > cc:
> > Subject:  RE: Data in SCSI Response or SCSI Data
> >
> >
> >
> >
> > Julo,
> >
> > Is it compliant to assume knowledge of the TCP frame by the iSCSI
> > application?  In many places within iSCSI discussions, references are
> made
> > of packets, frames, and datagrams as an element within iSCSI.  If
> creating
> > frame alignment is your intent, rather than corrupting TCP APIs, perhaps
> > you
> > should consider SCTP.  Otherwise, such discussions are little more than
> a
> > wink and a nod at creating a frame aligned TCP.  How do you
> > advise a change
> > to the TCP API to resolve frame alignment as you have just suggested?
> >
> > Doug
> >
> > > -----Original Message-----
> > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > > julian_satran@il.ibm.com
> > > Sent: Saturday, August 26, 2000 2:28 AM
> > > To: ips@ece.cmu.edu
> > > Subject: Re: Data in SCSI Response or SCSI Data
> > >
> > >
> > >
> > >
> > > Steph,
> > >
> > > I assume that your hardware knows when it is going to send the last
> SCSI
> > > datagram.
> > > In this case it can insert the status in the datagram header (not at
> the
> > > end) -
> > > (and BTW that is how the current draft assumes that things will
> > be done).
> > >
> > > If you have to send sense-data (bad status) then you will send
> > a separate
> > > datagram.
> > >
> > > Julo
> > >
> > > Stephen Bailey <steph@cs.uchicago.edu> on 25/08/2000 22:12:09
> > >
> > > Please respond to Stephen Bailey <steph@cs.uchicago.edu>
> > >
> > > To:   ips@ece.cmu.edu
> > > cc:    (bcc: Julian Satran/Haifa/IBM)
> > > Subject:  Re: Data in SCSI Response or SCSI Data
> > >
> > >
> > >
> > >
> > > > Is there anything preventing your hypothetical hardware implementor
> > > > to send always good status within the last block of data?
> > >
> > > It depends upon the RDMA mechanism you are using.  I admit that I have
> > > not studied them in detail, other than ST of course, which is
> > > essentially an transport protocol based upon a particular RDMA
> > > mechanism.  I will try to do so soon to determine if I'm all wet.
> > >
> > > However, assuming that the RDMA mechanism operates on a per-datagram
> > > basis, I can only imagine that you will not be able to append
> > > `general delivery' data to the end of an RDMA datagram.  In this case,
> > > you will need a separate datagram to ensure that status is delivered
> > > through a separate path from the data.
> > >
> > > So, while I think concatenating status and data in its general form is
> > > not a good idea, a good-status fast path (like the success bit) is
> > > definitely the right way to think about it.  Nonsuccess SCSI status is
> > > so rare that any compromise you can make in the nonsuccess path to
> > > make the success path go faster is worth it.
> > >
> > > Steph