RE: iSCSI: draft 7: iSCSI response and SCSI sense data

[Black_David@emc.com]

In my lousy Indiana Jones impression - "ACA, why does it
always have to be ACA?" ....

This whole notion that ACA is a fundamental coordination
mechanism for shared SCSI access to a target is not headed
in a good direction - see the recent message from Ralph Weber
expressing T10's concern that expansion of the usage of ACA is
an invitation to undesirable denial of service possibilities.
I will note that the reservation example that Ralph used in his
message is the sort of thing that can break clustering software,
although I don't know for certain whether there's any existing
clustering software that it does in fact break.

I think Rob and Jim are correct when they describe the current
2.4.3 text as being at odds with SAM-2.  So, I think:

- The text in 2.4.3 that is at odds with SAM-2 should come out.
	The fact that it was caused by a desire to use ACA makes
	it doubly suspect.
- The current mandate for ACA in Section 8.2 exceeds the level
	stated in the iSCSI requirements draft and I don't believe
	it represents rough consensus of the WG.  Support for
	ACA should be a "SHOULD", not a "MUST".
- The entire effort to use ACA or something like it to serialize
	error conditions for multiple commands in flight has not been
	explained well to T10, and what has been explained has not
	received a good reception.

The last bullet has a couple of consequences.  First, we should 
take out anything else that's crept into iSCSI in support of this
use of ACA.  Second, those who want to use ACA or something ACA-like
for this error coordination across multiple commands in flight
should write up a submission to T10 explaining what the problem
is and how ACA or something like it solves the problem.

I think Ralph is conveying a message from T10 that whatever the
problem iSCSI has, T10 is not inclined to believe that more use
of ACA is NOT the solution.  It may take a while to work with T10
to get the right solution designed, but I'd prefer doing nothing
over force-fitting ACA to a use that T10 doesn't think is appropriate.
When we figure out what the right thing is, we can put in the right
text to describe it.

Comments?
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------



> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Wednesday, August 01, 2001 8:01 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data
> 
> 
> 
> Elliot,
> 
> This issue has some history.  After many took the position you are
> advocating
> and I had to drop the check condition all list participants that had
> something to say adopted the current position in order the 
> benefit from the
> "serializing" effect of ACA whenever a check condition is 
> originated at the
> target and the delivery subsystem is still operational.
> 
> Julo
> 
> 
> "Elliott, Robert" <Robert.Elliott@compaq.com> on 02-08-2001 02:26:57
> 
> Please respond to "Elliott, Robert" <Robert.Elliott@compaq.com>
> 
> To:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
> cc:
> Subject:  iSCSI: draft 7: iSCSI response and SCSI sense data
> 
> 
> 
> 
> iSCSI draft 7 section 2.4.3 includes a table relating the iSCSI
> response codes to various CHECK CONDITION status additional
> sense codes:
> 
>   "0x01 Target Failure
>     ASC=0x44 ASCQ=0x00 INTERNAL TARGET FAILURE
>   0x02 Delivery Subsystem Failure
>     ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
>   0x03 Unsolicited data rejected
>     ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
>   0x04 Not enough unsolicited [data]
>     ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
>   0x05 SNACK rejected [Command in progress]
>     ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
> 
>   As listed above, each defined response code MUST be used (under the
>   conditions described in the 'Reason' field), only when the
>   corresponding SCSI CHECK CONDITION is signaled, to convey additional
>   protocol service information.  A SCSI CHECK CONDITION with the ASC
>   and ASCQ values as tabulated MUST be signaled by iSCSI targets for
>   all the instances in this document referring to usage of one of the
>   above defined response codes."
> 
> No other SCSI protocol does this. iSCSI seems to be granting the
> SCSI-level status a priority over the iSCSI-level response data.
> I think the other protocols treat the response data as more
> important; if the response data indicates a problem, the SCSI layer
> is considered broken and the SCSI status is undefined.
> 
> Forcing the iSCSI layer to fill in those fields seems to break the
> layering model.
> 
> I suggest removing the CHECK CONDITION status and additional sense
> code linkage and leave the SCSI status undefined if the iSCSI
> response is nonzero.
> 
> This is compatible with SAM-2, which only requires status be returned
> when the service response is TASK COMPLETE (SAM-2 revision 18
> section 5.3.1):
>   "Status shall be sent from the logical unit to the application
>    client whenever a command ends with a service response of
>    TASK COMPLETE or LINKED COMMAND COMPLETE."
> 
> Furthermore, SAM-2 requires that status be ignored when the service
> response indicates an error (SAM-2 revision 18 section 5.1):
>   "Status: A one-byte field containing command completion status
>   (see 5.3). If the command ends with a service response of
>   SERVICE DELIVERY OR TARGET FAILURE, the application client
>   shall consider this parameter to be undefined."
> 
> I think iSCSI's current wording may violate this rule.
> ---
> Rob Elliott, Compaq Server Storage
> Robert.Elliott@compaq.com
> 
> 
> 
>