Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data

From: "Julian Satran" <[email-masked]>
Date: Thu, 2 Aug 2001 03:00:31 +0300

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" <[email-masked]> on 02-08-2001 02:26:57

Please respond to "Elliott, Robert" <[email-masked]>

To:   "[email-masked]'" <[email-masked]>
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
[email-masked]

---

From: Stephen Bailey <[email-masked]>
Date: Wed, 01 Aug 2001 21:11:36 -0400

Robert,

> This issue has some history.

I agree that the mapping from response codes to check conditions,
while explanatory, is not appropriate in the iSCSI spec.  I think we
HAVE made a muddle of what's been a somewhat clear, acceptable
tradition.

The key technical point is that a SCSI target SHOULD (and we should
make this a MUST by providing no other mechanism) report every error
that it can report within the confines of SCSI status using SCSI
status.

Specifically, for every SCSI Command PDU, the target should return a
valid SCSI status, or nothing at all (e.g. timeout).

In my opinion, FCP did not necessarily get this quite right, but some
target's do the right thing implementations actually do the right
thing anyway.  Specifically, the definition of the response codes
seems to suggest that if you set both data direction bits (R&W), or
perhaps set the data direction in opposition to the command, you
should get an RSP_CODE=FCP_CMND fields invalid.  It's quite irritating
that FCP targets have this choice, and while one alternative (picking
SCSI status, e.g. 0xb/0x4700---parity error is traditional) can be
signalled cleanly to the end client (the class driver), the other may
be more difficult.

Really, the best use for response information in FCP is to return
status on task management operations.  In this case, SCSI doesn't
define particular status values anyway.  Given that iSCSI have separate
the SCSI Response and Task Management Response PDUs, I don't see why
we need Response information in the SCSI Response at all.  I think we
should dump this field completely.

I particularly think that `target failure' and `delivery subsystem
failure' are two status that should never be explicitly communicated
from the target to the initiator.  These are statuses that the
initiator infers as a result of something like a timeout, a link state
change, or whatnot.

Steph