RE: iSCSI : Holes in StatSN

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

Julian,

While I agree data delivery directed by the target with significant freedom
is the convention used by SCSI, Santosh also speaks to a much larger issue.
The present iSCSI transport is not reliable and repairing this weakness
using the SCSI layer is a poor technique.  Abandon a mixture of SCSI and
iSCSI and make iSCSI a self sustaining independent layer.  View iSCSI as a
general transport that allows handling of digest errors, validation,
multiple connections, and sequential delivery then its header may look
something like this:

  +---------------+---------------+---------------+---------------+
 0|    Type       |   Reserved    |          Word Length          |
  +---------------+---------------+---------------+---------------+
 4|                         Validation Tag                        |
  +---------------+---------------+---------------+---------------+
 8|                       Checksum (Adler32)                      |
  +---------------+---------------+---------------+---------------+
12|                    ->ClientSN or <-ServerSN                   |
  +---------------+---------------+---------------+---------------+
16|                 ->ExpServerSN or <-ExpClientSN                |
  +---------------+---------------+---------------+---------------+
20|                 ->MaxServerSN or <-MaxClientSN                |
  +---------------+---------------+---------------+---------------+


  +---------------+---------------+---------------+---------------+
24|                          (Frame Check)                        |
  +---------------+---------------+---------------+---------------+
28|                       SCSI_CMND  ...                          |
  +-                                                              |
36|                                                               |
  +---------------+---------------+---------------+---------------+
40|                       CDB ...                                 |
  +---------------+---------------+---------------+---------------+
x |                      (Data ...)                               |
  +---------------+---------------+---------------+---------------+

The advantage of moving the Frame Check (if used) into the header would be
with respect to data placement especially in regard to potential overlays or
non-sequential data due to the freedom offered to SCSI.  To assist in
delineating this transport as independent of SCSI a better name could be
SCSI Encapsulation Transport or SET.  To indicate its use under IP, iSET.
The frame type could include FC or Parallel versions of SCSI to assist in a
more straight forward conversion.

Doug

> Santosh,
>
> Overlaps and out of order delivery and gaps are not forbidden by SAM . I
> think we have to go to T10 for that I can't see a good reason to do it. We
> have a good solution without asking for it .  I can see large and
> important
> future application that will relay on overlaps and/or gaps and I am not
> going to foolishly do something to disable or harm their efficient
> implementation.  I think that T10s philosophy of keeping the target master
> of the transfer and not limiting it in any way is too valuable to ignore.
>
> IMHO your request violates our charter without any good reason to support
> it.
>
> Julo
>
> Santosh Rao <santoshr@cup.hp.com> on 01/02/2001 03:53:13
>
> Please respond to Santosh Rao <santoshr@cup.hp.com>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  Re: iSCSI : Holes in StatSN
>
>
>
>
> julian_satran@il.ibm.com wrote:
>
> > With a data sequence we may want to use a similar mechanism to ask for a
> > missed data block as soon as we see one of its successors or the status.
>
> Julian,
>
> The missing data PDU is missing due to either a header format
> error, header
> digest error or data digest error. [in all other cases, TCP ensures
> reliable
> delivery].
>
> In 2 of the above 3 cases, [header format error & header digest error] the
> initiator CANNOT do a safe interpretation of the PDU header. Without
> interpreting the PDU header, the initiator does NOT get the Initiator Task
> Tag. Any request to re-send a particular data PDU MUST be qualified by :
> I.T.T + missing_DataSN [+ T.T.T + CmdSN, optionally].
>
> Since I.T.T. cannot be reliably determined in 2 of the 3 cases, such a
> re-send request cannot be reliably achieved.
>
> The alternate proposal that was made should be considered in its place,
> which
> was to :
> - dis-allow overlapped data xfer's
> - initiators do a count check
> - a command level retry is performed at the iSCSI layer on detecting an
> underrun [due to a missing PDU].
>
> On several ocassions, requests from different people have been
> made on this
> list to dis-allow overlapped data xfers. Can a WG consensus be sought on
> this
> issue to see if the benefits of allowing overlapped data xfer's offset its
> complexities and justify its support ?
>
> Regards,
> Santosh
>
>  - santoshr.vcf
>
>
>
>