Subject: [Ips] iSCSI: Recovering from DataDigest error on SCSI_CMD PDU with ImmediateData

From: "Pittman, Joseph" <[email-masked]>
Date: Wed, 27 Oct 2004 11:27:02 -0400

On August 3-4 2004, I posed a question to this mailing list about the
legitimacy of the following behavior on the part of an iSCSI target:
 
- Target receives SCSI_CMD PDU with Immediate Data attached
- Target temporarily has no room to record immediate data, and
  so discards it
- Target gets around to processing SCSI Write command
- Target uses R2T to request (re-)transmission of the FirstBurst
  of data
 
The answer I received from the iSCSI spec authors (Thanks!) was that
this behavior is acceptable (especially in an error situation), and a
compliant initiator MUST provide the data (again) in response to
the R2T in this situation.

Now, I have a question about a different error condition involving
ImmediateData -- a DataDigest error.
 
Consider a hypothetical iSCSI target with the following pipelined
architecture for handling inbound data:
 
  +----------------------+
  | iSCSI Session Layer  |    - Receives PDU headers
  +----------------------+    - Performs iSCSI session management
                              - Drives SCSI data transfer
 
  +----------------------+
  | PDU Processing Layer |    - Forwards PDU headers immediately upon
receipt,
  +----------------------+      along with HeaderDigest valid indication
                              - Holds data segments in layer-private
memory
                              - Verifies DataDigest values, and reports
                                detected errors, only when data is
forwarded
                                up to the session layer
 
  +----------------------+
  | TCP/IP, NIC, etc.    |
  +----------------------+

Consider the handling by this architecture of a data digest error
on a SCSI_CMD PDU with ImmediateData.
 
1) The session layer would begin processing the SCSI command (and
   possibly some others later in the command sequence).
 
2) The session layer would NOT know about the data digest error yet,
   since that specific error is not recognized until the data is
   later retrieved as part of the data transfer phase
 
3) So the session layer would NOT send a Reject PDU
 
4) When the session layer goes to retrieve the immediate data which
   is being held in the PDU processing Layer, then the session layer
   would learn of the data digest error
 
5) PROPOSED RECOVERY ACTION: The session layer would discard the
   immediate data, and use R2T to request retransmission by the
   initiator.

Practically speaking, I think the proposed recovery action would be
guaranteed to work.  Because, from the initiator's point of view,
the target would be behaving exactly as described in the August 3/4
discussion mentioned above ("drop ImmData due to resource constraints").
 
I am, however, aware of the following statement in the spec surrounding
the handling of data digest errors:
 
  6.7 Digest Errors
 
  When a target receives any iSCSI PDU with a payload digest error, it
  MUST answer with a Reject PDU with a reason code of
  Data-Digest-Error and discard the PDU.

Two questions:
 
1) Can anyone think of a situation where the PROPOSED RECOVERY ACTION
   would not sufficiently handle the error?
 
2) Would a target behaving in this way be in definite violation of the
   spec?  Or are there perhaps some other statements in the spec which
   would render this behavior legitimate?
 
   An authoritative ruling from some of the specification authors and
   experts would be GREATLY appreciated.

Thanks very much for any help.
--
Joe Pittman
[email-masked] <mailto:[email-masked]> 

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: Julian Satran <[email-masked]>
Date: Sat, 30 Oct 2004 09:46:49 +0200

We discussed this exact topic in 2002 and decided that the spec should 
mandate reject WHEN the DIGEST ERROR IT IS SEEN (as it is a good practice 
to notify that there must be something bad on the path (digest errors do 
not happen by chance). However in you architecture the recovery action is 
legitimate - as the initiator has no way of distinguishing if the target 
experienced a digest error or a buffer failure and  the target has not 
seen yet the error . It can be argued that from a RAS point of view it is 
not the best practice - you will want to keep track of the digest errors 
as those are indicative of a problem on the path. You can handle those 
also within the management interface.

I hope that helps,

Julo

"Pittman, Joseph" <[email-masked]> 
Sent by: [email-masked]
27/10/04 17:27

To
<[email-masked]>
cc

Subject
[Ips] iSCSI: Recovering from DataDigest error on SCSI_CMD PDU with 
ImmediateData

 

 
  +----------------------+
 
  +----------------------+
 
  +----------------------+
  | TCP/IP, NIC, etc.    |
  +----------------------+

 

 

 
  6.7 Digest Errors

Two questions:

 

[email-masked]