RE: Data in SCSI Response or SCSI Data

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

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Matt Wakeley
> Sent: Friday, September 08, 2000 10:42 PM
> To: IPS Reflector
> Subject: Re: Data in SCSI Response or SCSI Data
>
>
> Douglas Otis wrote:
>
> > > > then it should send a response structure as FCP and not one
> or two and
> > > > use it according to FCP.  Undefined information of what some
> > > consider SCSI
> > > > values cause variants in use.  I have not seen tape drives use
> > > Good Sense
> > > > residual but vary in how Check Sense residual is presented.  If
> > > iSCSI is to
> > > > copy FC, then why deviate on response symmetry?  At least this
> > > provides an
> > > > easier bridge.  Iterative read operations will carry unused
> values to be
> > > > examined and opens the door for further variants.  Status
> > > presented prior to
> > > > data must then ensure sequence without end confirmation.
> > >
> > > Who said anything that status was presented before data?
> > > iSCSI allows the LAST iSCSI PDU that completes a SCSI command to
> > > also contain
> > > the GOOD SCSI status in the header, so that extra overhead to
> > > send the status
> > > PDU.
> >
> > By placing status within the header of perhaps 4G of data
> payload with no
> > defined end structure leaves nothing known to follow this transfer.  By
> > making Response a separate structure that physically follows the data
> > payload there is an end confirmation.  Should there be an error
> in sequence,
> > data will be accepted followed by perhaps some unknown command responses
> > until everything falls back into sync.  A dubious savings having dummy
> > status in each read exchange to save one possible structure at the end.
> > Rather than processing one response structure, you must process
> two where
> > one is out of sequence to the function.
> >
> > Doug
>
> Doug, this is TCP - a guaranteed byte stream.  If the target
> successfully reads
> 4G of data off its media into cache memory, and transmits it as one iSCSI
> message, TCP will deliver the data/message.  If TCP fails for
> some reason to
> deliver the message (and everything after it), then the initiator
> knows because
> the number of bytes read from TCP do not match the length of the
> iSCSI message
> (indicated in the header).  Now, if the header also indicates
> good status (as
> read from the target media into target cache), what's the big
> deal that its in
> the header as opposed to a separate message after the data iSCSI message?
>
> -Matt

Matt,

With multi-path, session recovery, or buffer errors possible (unrelated to
TCP) such that after the frame carrying PDU 0x45 status as a transfer is
started, completion with many frames of an opaque data glob removes the
ability to signal an error to prevent corrupted data from being accepted.
It seems to be opening the door for a nasty problem- Data accepted without
final confirmation.  FCP at least provides this final opportunity with an
ending Response PDU and it keeps the data transfer structure unencumbered
with optional fields.

Doug