RE: iSCSI version 20 draft

[Black_David@emc.com]

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
----------------------------------------------------