Message-ID: <003601c2c3d9$e43085e0$edd52b0f@rose.hp.com>
From: "Mallikarjun C." <cbm@rose.hp.com>
To: <Black_David@emc.com>, <ips@ece.cmu.edu>
References: <277DD60FB639D511AC0400B0D068B71E0564C80A@corpmx14.us.dg.com>
Subject: Re: iSCSI version 20 draft
Date: Fri, 24 Jan 2003 10:52:11 -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

David,

Let me note that both ACA and UA interlock are valid command ordering
mechanisms and both are SAM-2 concepts.

> I disagree, Section 5.9.1.2 of SAM-2 (sam2r24) says:
> 
>   When a device server terminates a command with a CHECK CONDITION status,
>   either an CA or ACA condition is established within the task set.
> 
> That's sufficient language to cause establishment of ACA.

Completely agreed wrt ACA.  But let's be careful wrt UA interlock, for a CA 
*does not* trigger a UA interlock.  A UA interlock is triggered on a UA, and a
UA can only be mandated in the iSCSI spec for the case of "a connection loss 
with the I_T nexus intact".  That's all Rob's second para is attempting to cover
along with the rationale (The orginal rev19 text mandated UA for the same reason).

> This creation of a new unit attention to deal with this situation
> (e.g., so that an initiator can control command ordering in these
> implicit termination cases without resorting to ACA) is a functional
> addition to iSCSI, complete with assignment of a new unit attention
> code; it does not appear to fix anything that is broken. 

IMHO, a UA is *not* a "functional addition" to iSCSI, a UA has been 
in the iSCSI spec for several months!

There are a couple of options I can think of to deal with this -

A. Rob's UA text with the original (rev19) ASC/ASCQ values.
B. Rob's UA text with no ASC/ASCQ values.
C. Rob's UA text with his proposed ASC/ASCQ values.

Perhaps your comment is specifically about Option.C.  I can agree with
you on that procedural aspect.  Out of A and B, I have a mild preference
for A (because I believe there's some value in consistency across all targets,
for an initiator), but I'd be okay with Option.B.

Hope that clarifies the technical issue.

Thanks.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com

----- Original Message ----- 
From: <Black_David@emc.com>
To: <cbm@rose.hp.com>; <ips@ece.cmu.edu>
Sent: Thursday, January 23, 2003 5:45 PM
Subject: RE: iSCSI version 20 draft


> Mallikarjun,
> 
> > > For this to go into the final RFC, I need a crisp explanation
> > > of what's broken in the -20 text.
> > 
> > That's fair.  There are two reasons.
> > 
> > - Cases a, b and c in the rev20 text below are *not* covered by SCSI
> >    standards in the case of single connection failures in a
> multi-connection
> >    session by definition, because the I_T nexus is still intact.
> Implementers
> >    cannot take guidance from SAM-2 or SPC3 as the text suggests.
> > 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]).
> 
> I disagree, Section 5.9.1.2 of SAM-2 (sam2r24) says:
> 
>   When a device server terminates a command with a CHECK CONDITION status,
>   either an CA or ACA condition is established within the task set.
> 
> That's sufficient language to cause establishment of ACA (if NACA is
> set) in all four cases as it has no dependency on continued
> existence of the I_T nexus.  So, although Rob's first paragraph may be
> more carefully edited than the existing text, it does not appear to
> fix anything that is actually broken.
> 
> > -  Command ordering even in the face of errors for an I_T nexus is
> >     what iSCSI signed up to do quite a while ago (Nashua F2F?).  The
> >     careful line we've been treading is that iSCSI doesn't require
> >     initiators to use command ordering, but iSCSI specifies the
> >     guaranteed target semantics _in case_ the initiator wants to
> >     employ it.  A single connection drop in a multi-connection
> >     session is clearly an iSCSI scenario that could violate the
> >     command ordering, and the target ordering semantics in this
> >     case will have to be clearly called out in the iSCSI RFC
> >     as elsewhere.
> 
> I don't see any additional rationale here beyond the original
> statement that SAM-2 does not apply ACA to events that don't destroy
> the I_T Nexus - see above.
> 
> Going on to Rob's second paragraph, I have to throw a "process" flag
> on the play.  Rob describes his paragraph as:
> 
> > 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.
> 
> This creation of a new unit attention to deal with this situation
> (e.g., so that an initiator can control command ordering in these
> implicit termination cases without resorting to ACA) is a functional
> addition to iSCSI, complete with assignment of a new unit attention
> code; it does not appear to fix anything that is broken.  While I'm
> inclined to believe that this is a useful "nice to have" addition,
> I believe adding it at this late stage is out of bounds, and I'm
> concerned that working through the detailed implications will take
> us into SAM-3's I_T nexus loss handling, where I believe we do not
> want to go.
> 
> So, I do not see the need for any text changes to -20.
> 
> In order not to lose the careful thinking that has gone into this
> issue, could I suggest that you and Rob write up an Internet-Draft on
> this topic?  A good discussion of what ACA does and how to use it
> would doubtless be useful to implementers who do not have the benefit
> of T10's experience in this area.  That draft could also propose
> the new unit attention condition and code, but would probably need
> to make it OPTIONAL.
> 
> Sorry/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
> ----------------------------------------------------
> 
>