Return-Path: X-Sieve: cmu-sieve 2.0 Return-Path: Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id h0N62hJ25362 for ips-outgoing; Thu, 23 Jan 2003 01:02:44 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h0N62fW25357; Thu, 23 Jan 2003 01:02:41 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0N62YlK070970; Thu, 23 Jan 2003 07:02:34 +0100 Received: from d10ml001.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0N62Rm5117230; Thu, 23 Jan 2003 07:02:28 +0100 In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C7EF@corpmx14.us.dg.com> To: Black_David@emc.com Cc: cbm@rose.hp.com, ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI version 20 draft MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: "Julian Satran" Message-ID: Date: Thu, 23 Jan 2003 08:02:26 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 23/01/2003 08:02:32, Serialize complete at 23/01/2003 08:02:32 Content-Type: multipart/alternative; boundary="=_alternative 00207AEDC2256CB7_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00207AEDC2256CB7_= Content-Type: text/plain; charset="US-ASCII" 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)" > To: > 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 > > > > --=_alternative 00207AEDC2256CB7_= Content-Type: text/html; charset="US-ASCII"
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
> >
>
>

--=_alternative 00207AEDC2256CB7_=--