Re: Data in SCSI Response or SCSI Data

[julian_satran@il.ibm.com]

Randall,

Your comments are valuable - but I don't exactly see how they relate to
iSCSI as drafted
(although I see how they relate to Doug's comments).

Julo

"Randall R. Stewart" <randall@stewart.chicago.il.us> on 29/08/2000 00:47:58

Please respond to "Randall R. Stewart" <randall@stewart.chicago.il.us>

To:   Douglas Otis <dotis@sanlight.net>
cc:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
Subject:  Re: Data in SCSI Response or SCSI Data




Douglas:

Your notes below are along the sender side path i.e. the pusher :)

But it is even worse on the receiver side. Unless the receiver
puts record markings in and observes them very carefully what you
get at each read is really quite dependant on the kernel buffering
and what as arrives since you last did a read...

Generally stuff I have seen and done in the past either is sending
"fixed" records of exactly the same number of bytes so it can
do a blocking read to get X bytes ... OR the old tried
and true:

A) read the int size

followed by

B) read until you fill the buffer you are expecting based
   on the int size you got...

El.Yucko if you are doing any sort of message
sending/receiving... which I presume iSCSI does...

If it does not have clear delineation via fixed records OR
a size indicator in a common header that is always read this
will be a problem :0

R



Douglas Otis wrote:
>
> 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

--
Randall R. Stewart
randall@stewart.chicago.il.us or rrs@cisco.com
815-342-5222