RE: Data in SCSI Response or SCSI Data

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

Julo,

My apology for the misunderstanding.  PDU is defined as Protocol Data Unit
within the iSCSI spec.  Using datagram, packet or frame is not a good choice
of terminology if the meaning is PDU as it implies a far different meaning
with respect to IP.  We were speaking past each other with these unfortunate
terms.  Much as I think RTT is not a good mnemonic with respect to a
standard intended to run on IP protocols.  I guess I should first quiz the
terms.  Although I think I made my concerns clear, it is obviously a
confusion based on terminology.

Doug

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> julian_satran@il.ibm.com
> Sent: Wednesday, August 30, 2000 2:24 AM
> To: ips@ece.cmu.edu
> Subject: RE: Data in SCSI Response or SCSI Data
>
>
>
>
> The datagrams I am referring in the note to Steph are iSCSI PDUs. No
> relation whatsoever to TCP PDUs or IP PDUs.
>
> Julo
>
> "Douglas Otis" <dotis@sanlight.net> on 29/08/2000 20:27:57
>
> Please respond to "Douglas Otis" <dotis@sanlight.net>
>
> To:   Black_David@emc.com, Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> cc:
> Subject:  RE: Data in SCSI Response or SCSI Data
>
>
>
>
> David,
>
> Clearly, the URGENT flag does even less at defining a point within the TCP
> stream.
>
> RFC 793 (TCP pg 12 & 13 continued.)
>
>   "TCP also provides a means to communicate to the receiver of data that
>   at some point further along in the data stream than the receiver is
>   currently reading there is urgent data.  TCP does not attempt to
>   define what the user specifically does upon being notified of pending
>   urgent data, but the general notion is that the receiving process will
>   take action to process the urgent data quickly."
>
> Care should be taken not to make assumptions as to the behavior of TCP
> regarding frame alignment.  These assumptions are being made by Julian in
> describing iSCSI placement of information.  His being evasive
> does not help
> with assessments under such erroneous expectations.  In
> describing iSCSI as
> being able to place information in specific datagrams, Julian
> modifies TCP.
>
>  "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  Aug 26, 2000  RE: Data in SCSI Response or SCSI Data
>
> Julian should clarify where in the iSCSI draft these assumptions he
> indicates exist.  No where within the iSCSI document is datagram
> defined or
> used; should it be if this behavior is required?  Perhaps there is no
> expectation of adhering to TCP specifications in the implementation of
> iSCSI
> and leaving out this information from iSCSI is an attempt to hide
> these TCP
> modifications.
>
> Doug
>
>
> > -----Original Message-----
> > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > Sent: Tuesday, August 29, 2000 6:38 AM
> > To: dotis@sanlight.net; julian_satran@il.ibm.com; ips@ece.cmu.edu
> > Subject: RE: Data in SCSI Response or SCSI Data
> >
> >
> > 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
> >
>
>
>
>