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

From: "Elliott, Robert" <[email-masked]>
Date: Wed, 1 Aug 2001 18:26:57 -0500

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: "Dev" <[email-masked]>
Date: Wed, 1 Aug 2001 18:01:12 -0700

Robert,

I agree with you fully on this.  

---

------

Thanks

Deva
Platys Communications

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Elliott, Robert
Sent: Wednesday, August 01, 2001 4:27 PM
To: [email-masked]'
Subject: iSCSI: draft 7: iSCSI response and SCSI sense data

  "0x01 Target Failure

---

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 01 Aug 2001 21:05:31 -0700

Robert and all,

As the one who suggested that wording into the draft, let me 
add some comments. (Please see
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05089.html
for my initial proposal.)

> code linkage and leave the SCSI status undefined if the iSCSI

I agree, as Steph already alluded to in a separate email, the ideal 
solution appears to: 
          a) drop the response code *definitions* (ie. leave
             room for vendor-unique codes) altogether, and
          b) continue to specify the right SCSI CHECK CONDITION 
             (ASC, ASCQ) values for the iSCSI error events (such
             as digest failures).

As I said in the earlier referenced message "mandate a standard 
SCSI CHECK CONDITION on these errors with the current response codes 
acting as detailed descriptions.".  But you bring up a good point 
that this "detailed descriptions" may be violating SAM-2's expectations. 

> Forcing the iSCSI layer to fill in those fields seems to break the

I disagree.  If the affected SCSI task can be reliably ascertained
by the target, it appears highly desirable to report the status 
using a SCSI CHECK CONDITION.  Target iSCSI layer has to internally
terminate the pre-instantiated SCSI task anyway informing its SCSI 
layer of the fact.  Besides, there are precedents in FCP-2 for similar
cases where the task is identifiable.

Regards.
-- 
Mallikarjun 

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668 Hewlett-Packard, Roseville.
[email-masked]

---

From: "Dev - Platys" <[email-masked]>
Date: Wed, 1 Aug 2001 17:52:41 -0700

Robert,

I agree with you on this.  

---

------

Thanks

Deva
Platys Technologies

  "0x01 Target Failure