Re: Data in SCSI Response or SCSI Data

["Robert B. Harmon" <bharmon@osicom.com>]

I have had to fix/debug TCP once, no 3 three times, soo..

TCP has 2 parts to urgent mechanism.
and URG flag in header to indicate that urgent field is "significant"
The URGENT pointer itself is an offset from the indicated sequence
number,
   (the sequence number of "this" segment").

I have heard that there is generally very little use of URGENT.

A better place to read about this is the TCP man page, showing its use
in a sockets program.
     TCP provides an urgent data mechanism, which may be  invoked
     using  the  out-of-band  provisions of send(3N).  The caller
     may mark one byte as  "urgent"  with  the  MSG_OOB  flag  to
     send(3N).   This  sets  an "urgent pointer" pointing to this
     byte in the TCP stream.  The receiver on the other  side  of
     the  stream  is notified of the urgent data by a SIGURG sig-
     nal.  The SIOCATMARK ioctl() request returns a  value  indi-
     cating  whether  the  stream is at the urgent mark.  Because
     the system never returns data across the urgent  mark  in  a
     single read(2) call, it is possible to advance to the urgent
     data in a simple loop which reads data, testing  the  socket
     with  the  SIOCATMARK  ioctl() request, until it reaches the
     mark.                                                    


The TCP Push bit cannot be used.  Most if not all TCP implementations
always set the push bit.


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