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

[Black_David@emc.com]

I've got to stop writing email late at night ...

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

That should have been a single negative, not double. i.e., "T10
is 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.

At least that's still correct :-).

Sorry/Thanks,
--David

> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Wednesday, August 01, 2001 9:19 PM
> To: Julian_Satran@il.ibm.com; ips@ece.cmu.edu
> Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data
> 
> 
> 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
> > 
> > 
> > 
> > 
>