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

["Julian Satran" <Julian_Satran@il.ibm.com>]

Steph,

You change opinions faster than draft changes :-)

David,

Could you please quote us which part of SAM-2 this is violating. Please
keep in mind
that SAM has 2 return parameters in its Remote Procedure Call model that
can be sent independently.
FTP has following the older standards and set them exclusively but that is
not IMHO required by SAM.
ACA or not - we do require an interlocking mechanism. ACA can't be broken
that easy and certainly not that
total as you suggest.  And if we do not use the SCSI interlocking we will
have to invent a brand new one of our own.

And a procedural call - please do not quote layering as a reason for
tearing something down. Please quote a way of doing interlocking that is as
cheap as this and does not violate layering and I'll buy it.

A second line of argument says that layering is not a goal.

And a third says that all SCSI protocols access both SCSI level and
protocol specific functions that are common to all at the "SCSI levels".
That type of engineering is very common in computing (OSes are built this
way).
Interlocking is a problem for many protocols (not only iSCSI) and its
solution (for all) is at SCSI level. And ACA is a way to do interlocking
(there are not many others and yhey are all described in SAM).
If having it described in the same book means violating layering so be it
although I think that you are mistaken.

Regards,
Julo



Black_David@emc.com on 02-08-2001 04:19:27

Please respond to Black_David@emc.com

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
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
>
>
>
>