RE: iSCSI version 20 draft

["Julian Satran" <Julian_Satran@il.ibm.com>]

I completely agree with David.

We left in enough explanations for T10
to make its recommendation on the UA/ACA and the detailed code elsewhere
- as this type of behavior change (UA vs. ACA) is common to many check
conditions.

Also the detailed ASC/ASQ code is common
with other transports and can be stated in SPC3 (to which we refer).

Regards,
Julo

Black_David@emc.com
Sent by: owner-ips@ece.cmu.edu

23/01/03 02:10

To	cbm@rose.hp.com, ips@ece.cmu.edu
cc
Subject	RE: iSCSI version 20 draft

For this to go into the final RFC, I need a crisp
explanation
of what's broken in the -20 text.  I also dislike the fact that
this references SAM-3 - iSCSI has been primarily based on SAM-2
and the RFC should reference only SAM-2, which is stable, as opposed
to SAM-3, which is very much a work in progress and subject to
all sorts of changes.  At some point, we can undertake work to
update iSCSI to line up with SAM-3, but that's not an appropriate
thing to do at this final approval stage.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508)
293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> Sent: Wednesday, January 22, 2003 6:41 PM
> To: Elliott, Robert (Server Storage); ips@ece.cmu.edu
> Subject: Re: iSCSI version 20 draft
> 
> 
> 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 
> > 
> 
>