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

From: "Mallikarjun C." <[email-masked]>
Date: Mon, 01 Nov 2004 17:31:05 -0800

> 1) Can anyone think of a situation where the PROPOSED RECOVERY ACTION
 >    would not sufficiently handle the error?

The Error Recovery Team discussed this in great detail during 2001 and 
concluded that the proposed action is problematic for technical and 
implementation reasons.  Consequently, the RFC is quite unambiguous that 
accepting or discarding is at the PDU granularity - partial PDUs are not 
consumed on the receiver and no partial PDU recovery either.

 > 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?

I believe it would be a violation.  The spec is very explicit about your 
scenario.   In addition to the text you quoted, section 6.7 further says 
the following:

"....(for immediate data in a command PDU, non-data PDU rule
below applies),...."

and the non-data PDU rule says:
"In case of immediate data being present on
a discarded command, the immediate data is implicitly recovered
when the task is retried...."

Sorry....
-- 
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com

Pittman, Joseph wrote:

> 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

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