Fwd: BOUNCE ips@ece.cmu.edu: Non-member submission from [Robert Snively <rsnively@brocade.com>]

[Jim McKinney <jmck+@ece.cmu.edu>]

Return-Path: <owner-ips@ece.cmu.edu>
X-Sieve: cmu-sieve 2.0
Return-Path: <owner-ips@ece.cmu.edu>
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72Lg8T29518;
	Thu, 2 Aug 2001 17:42:08 -0400 (EDT)
Date: Thu, 2 Aug 2001 17:42:08 -0400 (EDT)
From: owner-ips@ece.cmu.edu
Message-Id: <200108022142.f72Lg8T29518@ece.cmu.edu>
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
To: owner-ips@ece.cmu.edu
Subject: BOUNCE ips@ece.cmu.edu:    Non-member submission from [Robert Snively <rsnively@brocade.com>]   

From owner-ips@ece.cmu.edu Thu Aug  2 17:42:06 2001
Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f72Lg6e29513
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 17:42:06 -0400 (EDT)
Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35])
	by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id OAA29006;
	Thu, 2 Aug 2001 14:38:39 -0700 (PDT)
Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19)
	id <Q12Z73MB>; Thu, 2 Aug 2001 14:38:39 -0700
Message-ID: <FFD40DB4943CD411876500508BAD02790299371D@sj5-ex2.brocade.com>
From: Robert Snively <rsnively@brocade.com>
To: "'cbm@rose.hp.com'" <cbm@rose.hp.com>,
   "Elliott, Robert"
	 <Robert.Elliott@compaq.com>
Cc: "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data
Date: Thu, 2 Aug 2001 14:38:38 -0700 
X-Mailer: Internet Mail Service (5.5.2653.19)

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