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

["Elliott, Robert" <Robert.Elliott@compaq.com>]

My view:
If a non-zero response code is present, the Status field is undefined
and the response data contains all information about the error (fed
from the iSCSI layer).

If the target is capable of reporting a Status, then the response
field is zero and the sense data contains all information about the
error (fed from the SCSI layer, which might communicate with the 
iSCSI layer internally to figure out some of the information).

---
Rob Elliott, Compaq Server Storage
Robert.Elliott@compaq.com



> -----Original Message-----
> From: Robert Snively [mailto:rsnively@brocade.com]
> Sent: Thursday, August 02, 2001 4:39 PM
> To: 'cbm@rose.hp.com'; Elliott, Robert
> Cc: 'ips@ece.cmu.edu'
> Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data
> 
> 
> I am not sure that complete removal of the response codes 
> is the best approach.  There are some things
> that SCSI devices can know nothing about, and only TCP links
> can know about.  There are other things that iSCSI state machines
> know about that logical units do not know about (usually software
> generated inconsistencies in the protocol procedures).  These are
> natural candidates for response codes.  Note that vendor 
> specific is a synonym for non-interoperable and also for
> undesirable.  It is far better to reserve anything like that,
> since the behavior in the presence of a vendor specific value
> is not defined.  While it is clear that may response codes should
> move over to CHECK CONDITIONS, I think that there are
> still some protocol related response codes that will be required.
> 
> Bob
> 
> -----Original Message-----
> From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> Sent: Wednesday, August 01, 2001 9:06 PM
> To: Elliott, Robert
> Cc: 'ips@ece.cmu.edu'
> Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data
> 
> 
> 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.)
> 
> > I suggest removing the CHECK CONDITION status and additional sense
> > code linkage and leave the SCSI status undefined if the iSCSI
> > response is nonzero.
> 
> 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
> > layering model.
> 
> 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.
> cbm@rose.hp.com
> 
> "Elliott, Robert" wrote:
> > 
> > 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
>