Re: iSCSI version 20 draft

["Mallikarjun C." <cbm@rose.hp.com>]

> 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]).

-  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 also dislike the fact that
> this references SAM-3

Agreed, I don't like it myself.  I believe the text would be just as correct with a
reference to SAM-2 - both ACA and UA interlock are SAM-2 concepts.  I
overlooked this in my first review.

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: Wednesday, January 22, 2003 4:10 PM
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
> > >
> >
> >
>