Subject: Re: iSCSI ERT: error recovery comments

From: [email-masked]
Date: Tue, 27 Mar 2001 15:12:01 +0200

Comments in text.  Thanks Julo

"Mallikarjun C." <[email-masked]> on 27/03/2001 01:41:48

Please respond to [email-masked]

To:   [email-masked], [email-masked], [email-masked], Julian
      Satran/Haifa/IBM@IBMIL, John Hufferd/San Jose/IBM@IBMUS
cc:   [email-masked]
Subject:  iSCSI ERT: error recovery comments

Hi Julian and the Team,

Here are some comments on error recovery issues.  I hope these will
be addressed soon.  Thanks.

1. The draft should clearly state that if a target doesn't support
  retry (replay in my previous memo's terminology), it must not silently
  accept a command with retry bit and re-do the I/O.

2. Consequent to the above -
     - Clarification required on section 6.7.1, page 83, last para.
          Please confirm and clarify in the draft: If the target sends
          a response with an iSCSI error response of "SACK-rejected" that
          implicitly terminates the task - no retries are allowed. If the
          target sends a Reject PDU with "Data SACK Reject" code, the task
          stays open and the initiator may try to recover using SACK/retry.
+++ I will clarify
it will read:
   An iSCSI target MAY reject a data-SNACK and terminate the command with
   an iSCSI command response of SNACK rejected. In this case, the task is
   terminated and no future action is expected at target and initiator.

   Alternatively, an iSCSI target MAY reject a data-SNACK with a reject
   response of data SNACK rejected. In this case the task is still open and
   may be recovered using the retry.

+++
        - On a data digest error on a data PDU without the F-bit, the draft
          states that the target must wait for a data PDU with the F-bit
          (per section 6.2), then a command termination is signalled with
          a Reject PDU!  I like the formulation in 2.4.2 better.  I
strongly
          recommend that similarly, the target shall send a SCSI Response
          with a iSCSI response of "delivery subsystem failure".  In
general,
          I suggest that anytime a target terminates a task internally, it
          must generate a SCSI Response PDU with an appropriate response
code.
+++ It reads now:

   When a target receives an iSCSI PDU with a header digest error or a
   payload digest error in an iSCSI PDU, it MUST answer with a Reject iSCSI
   PDU with a Reason-code of Header-Digest-error or Data-Digest-Error and
   discard the offending PDU.  If the error is a Data-Digest-Error in a
   Data-PDU, the target MUST either request retransmission with a R2T or
   answer with a command response PDU with a response-code of
   delivery-subsystem-failure and abort the task. If the target is
   answering with an error in the command response PDU it must wait for the
   target to receive all the data (signaled by a Data PDU with the final
   bit Set for all outstanding R2Ts) the command response PDU.
++++

3. While the following is implied in different sections, it is not
  obvious.  Please clarify the following in the draft - "Status SACK
  support is mandatory, whereas data SACK support is not."

+++ will do in 2.16.1 +++

4. The general policy of retry should be that all ordered commands
  shall support retry bit, since the loss of an ordered command
  creates a hole in target scoreboarding and stalls the target
  pipeline.  Retry hopefully can plug the hole quickly to avoid this.

5. As a fallout of the above comment, Retry bit must be supported
  for Text Commands.

+++ I have added the X-bit.  The reason I did no earlier was that I could
not foresee
a case in which the command is not idempotent - I can allways be resent -
but I guess it is cleaner with the X +++

6. Section 2.20, page 71 on Reject must specify if a retry of the operation
  is allowed for each Reject PDU reason code.  Lack of specification could
  lead to interoperability issues down the road with "retry wars" raging
  between heterogeneous implementations (ex., target rejects the retry bit,
  initiator retries the "retry" bit,....).
+++ the part now reads:

   The reject Reason is coded as follows:

      1 - Format Error
      2 - Header Digest Error
      3 - Data (payload) Digest Error
      4 - Data-SNACK Reject
      5 - Command Retry Reject
      15 - Full Feature Phase Command before login

      Some of the reject reasons terminate or prevent the creation of a
      task at the target and no retry is possible in those cases. Format
      error for a command, Command Retry Reject and Full Feature Phase
      Command before login are in this category.

7. NOP-OUT does not require CmdSNs.  Why make it an ordered command
  and run the risk of a digest error on it leading to a hole in
  command ordering?

+++ the reason I wanted it ordered is to check the whole command path - but
you may try to convince me that it is not a good idea +++
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668   Hewlett-Packard, Roseville.
[email-masked]

---

From: [email-masked]
Date: Tue, 27 Mar 2001 15:12:01 +0200

Hi Julian and the Team,

+++

      1 - Format Error
      2 - Header Digest Error

Mallikarjun Chadalapaka