Message-ID: <001001c2c26f$b1517820$edd52b0f@rose.hp.com>
From: "Mallikarjun C." <cbm@rose.hp.com>
To: "Elliott, Robert (Server Storage)" <Elliott@hp.com>, <ips@ece.cmu.edu>
References: <78AF3C342AEAEF4BA33B35A8A15668C60296E7D9@cceexc17.americas.cpqcorp.net>
Subject: Re: iSCSI version 20 draft
Date: Wed, 22 Jan 2003 15:40:48 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Rob's suggested text (3rd and 4th paras below) covers the design
intent very well, I suggest that we incorporate it into the final RFC as-is.
It covers two crucial aspects in my opinion -

    -  Defines the SCSI behavior required of iSCSI/SCSI targets 
        in order to satisfy iSCSI's command ordering guarantee for
        an iSCSI-specific scenario (i.e. not covered by SAM/SPC),
        that of one connection failing in a multi-connection session.
       
    -  Describes in detail why the specified behavior is required - 
       ACA and UA interlock - which was clearly lacking in the original 
       text in rev19. 
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com


----- Original Message ----- 
From: "Elliott, Robert (Server Storage)" <Elliott@hp.com>
To: <ips@ece.cmu.edu>
Sent: Wednesday, January 22, 2003 10:34 AM
Subject: RE: iSCSI version 20 draft


> Sorry to belabor this, but the wording about the affects of connection 
> loss didn't end up like Mallikarjun's final recommendation.
> 
> Upon further discussion, we think this would be better:
> 
> If the tasks terminated in the above cases are SCSI tasks, they must 
> be internally terminated as if with CHECK CONDITION
> status. This enables ordering to be maintained correctly with respect
> to commands on other connections when ACA is enabled. This enables 
> ordering to be maintained correctly with respect to commands on other 
> connections of the same I_T nexus when ACA is enabled (i.e., commands
> waiting to be processed after those terminated are blocked due to
> the ACA) - see [SAM-3] and [SPC-3].
> 
> After the tasks are terminated, the device server shall report a unit 
> attention condition with an additional sense code of COMMANDS 
> CLEARED BY TRANSPORT PROTOCOL EVENT on the next command processed on 
> any connection for each affected I_T_L nexus. This enables ordering to 
> be maintained correctly with respect to commands on other connections 
> of the same I_T nexus when unit attention interlock is enabled (i.e., 
> commands waiting to be processed after those terminated are blocked 
> due to the unit attention interlock) - see [SAM-3] and [SPC-3].
> 
> 
> The first paragraph explains why the "CHECK CONDITION" part is
> important for the internally terminated tasks. If they were
> allowed to terminate as if they had "GOOD" status, they wouldn't
> invoke ACA.
> 
> The second paragraph explains the unit attention that must appear
> on the next command on the wire (and lists the additional sense
> code to use). This is not an additional sense code for an internal-only 
> command status, so is appropriate for iSCSI to mention. We'll assign 
> that code in SPC-3.
> 
> 
> The text in iscsi-20 is:
> 6.5 Implicit termination of tasks
> ...
> If the tasks terminated in the above cases a), b, c) and d)are
> SCSI tasks, they must be internally terminated as if with
> CHECK CONDITION status. This status is only meaningful for
> appropriately handling the internal SCSI state and SCSI side
> effects with respect to ordering because this status is never
> communicated back as a terminating status to the initiator.
> However additional actions may have to be taken at SCSI level
> depending on the SCSI context as defined by the SCSI standards
> (e.g., queued commands and ACA, UA for the next command on the
> I_T nexus in cases a), b), and c) etc. - see [SAM] and [SPC3]).
> 
> 10.14.5 Implicit termination of tasks
> ...
> If the tasks terminated in any of the above cases are SCSI
> tasks, they must be internally terminated as if with
> CHECK CONDITION status. This status is only meaningful for
> appropriately handling the internal SCSI state and SCSI side
> effects with respect to ordering because this status is never
> communicated back as a terminating status to the initiator.
> However additional actions may have to be taken at SCSI level
> depending on the SCSI context as defined by the SCSI standards
> (e.g., queued commands and ACA, UA for the next command on the
> I_T nexus in cases a), b), and c) etc. - see [SAM] and [SPC3]).
> 
> -- 
> Rob Elliott, elliott@hp.com 
> Hewlett-Packard Industry Standard Server Storage Advanced Technology 
> https://ecardfile.com/id/RobElliott 
> 
> 
> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com] 
> Sent: Sunday, January 19, 2003 11:52 PM
> To: internet-drafts@ietf.org
> Cc: ips@ece.cmu.edu; Allison Mankin
> Subject: iSCSI version 20 draft
> 
> 
> On behalf of the team of authors and as part of the IETF-IPS working
> group 
> I submit a draft for immediate publication. 
> 
> The text and pdf versions can be found at: 
> 
> http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-20.txt 
> http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-20.pdf 
> 
> This version completely replaces: 
> 
> draft-ietf-ips-iscsi-19.txt and pdf 
> 
> 
> The change marks are relative to version 19 and are clarifications
> as requested by Steve Bellovin and typo fixes. 
> All AD concerns and the "nits" where (hopefully) addressed. 
> 
> Julian Satran - IBM Research Laboratory at Haifa 
>