Subject: Re: iSCSI : Holes in StatSN

From: [email-masked]
Date: Thu, 1 Feb 2001 12:42:26 +0200

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 <[email-masked]> on 01/02/2001 03:53:13

Please respond to Santosh Rao <[email-masked]>

To:   [email-masked]
cc:
Subject:  Re: iSCSI : Holes in StatSN

[email-masked] 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

---

From: Santosh Rao <[email-masked]>
Date: Thu, 01 Feb 2001 11:02:30 -0800

Julian,

I did'nt hear back on my issues related to attempting per-PDU recovery, namely
:

a) This goes back to attempting to recover a portion of the I/O as opposed to
command level recovery. I believe the WG consensus at Orlando was to use
command level recovery (?)

b) A request to re-send a Data PDU within an I.T.T must be qualified by (I.T.T
+ missing_DataSN).
The I.T.T & DataSN CANNOT be reliably extracted from the PDU in the cases of a
header format error or header digest error. IOW, the per-PDU scheme does not
solve all the cases.

Regarding overlapped data xfers, FCP prohibited it and seems to have no
problems with this. Also, this feature is un-used in most cases. I don't
believe restricting iSCSI to support a sub-set of the optional features of
SAM-2 violates either T10 philosophy or SAM-2. OTOH, specifying guidelines
that mandate which features shall be used and un-used (along the lines of
FC-PLDA and FC-FLA documents) is the only reliable recipe for
interoperability.

Regards,
Santosh

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 1 Feb 2001 11:25:54 -0800

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