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 h07L0KW21439 for ips-outgoing; Tue, 7 Jan 2003 16:00:20 -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 h07L0GW21432; Tue, 7 Jan 2003 16:00:17 -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 h07L04MP050336; Tue, 7 Jan 2003 22:00:04 +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 h07L03jM044228; Tue, 7 Jan 2003 22:00:03 +0100 In-Reply-To: <001301c2b66a$be7eba00$6403a8c0@ivvt2dxrc11> To: Cc: "'Mallikarjun C.'" , ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI: Implicit Termination of Tasks MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: "Julian Satran" Message-ID: Date: Tue, 7 Jan 2003 23:00:00 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 07/01/2003 23:00:03, Serialize complete at 07/01/2003 23:00:03 Content-Type: multipart/alternative; boundary="=_alternative 00728C95C2256CA7_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00728C95C2256CA7_= Content-Type: text/plain; charset="US-ASCII" I am not sure a target is mandated to send a sense after the session went away! There are few things that survive such an event. You may want to consider the clearing effects appendix. Julo "Eddy Quicksall" Sent by: owner-ips@ece.cmu.edu 07/01/03 18:35 Please respond to To "'Mallikarjun C.'" , cc Subject RE: iSCSI: Implicit Termination of Tasks I think the point is that the target must set a Sense Key/ASC/ASCQ of 06/6E/00 internally because the next command could be a Request Sense and the target is a must to send 06/6E/00 since the previous command failed. Also, as you pointed out, the initiator may be using ACA in which case the ACA Active status would be sent (which lets the initiator take corrective action to maintain ordering). Am I correct? Eddy -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Monday, January 06, 2003 9:15 PM To: Eddy_Quicksall@iVivity.com; ips@ece.cmu.edu Subject: Re: iSCSI: Implicit Termination of Tasks Eddy, iSCSI's design goal was to ensure command ordering even in the face of errors - ultimately, we wanted the SCSI execution ordering to be correct while running on iSCSI. This should be able to be guaranteed by the iSCSI targets, while initiators may/may not employ command ordering. For this to happen, iSCSI must both maintain its delivery ordering, and require SCSI CHECK CONDITIONs to be locally triggered on the target on iSCSI exception conditions such as connection terminations. The CHECK CONDITION would then cause the ACA/persistent-UA to be invoked if so desired by the initiator. This is not "a method of implementing", it's required behavior to meet iSCSI's architectural guarantee of command ordering. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Eddy Quicksall" To: "'Mallikarjun C.'" ; Sent: Monday, January 06, 2003 12:46 PM Subject: RE: iSCSI: Implicit Termination of Tasks > Yes, I noticed my typo of "two" vs. "three" but too late. > > Below you say that the ordering is iSCSI ordering but section 6.5 is saying > SCSI ordering (queued commands is SCSI). So, that leaves me a little > confused as to what this paragraph is trying to say, especially when the > "status is never communicated back ... to the initiator". > > I'm probably mis-understanding something. It appears as though this is just > a method of implementing within the target. > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Monday, January 06, 2003 3:12 PM > To: Eddy_Quicksall@ivivity.com; ips@ece.cmu.edu > Subject: Re: iSCSI: Implicit Termination of Tasks > > > Comments below. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > ----- Original Message ----- > From: "Eddy Quicksall" > To: > Sent: Monday, January 06, 2003 5:16 AM > Subject: iSCSI: Implicit Termination of Tasks > > > > There are two sections titled Implicit Termination of Tasks but they > are > > slightly different. Which is correct? > > Both are correct and consistent. > > > > > Section 6.5 lists 4 items but section 10.14.5 only lists two. > > I'm seeing three in 10.14.5..... > > Even though 6.5 lists all the four cases, it makes it clear that the > check condition is to be employed only for three cases - and > only those three are listed by 10.14.5. Perhaps the text could have > been a little bit more explicit about this distinction. > > > > > If 6.5 is correct, why is item D not included in the unit attention? > SAM-3 > > says: > > It's not so much a SAM issue. The issue we considered was how to ensure > iSCSI-standard ordered delivery of commands in the face of errors. The > ordered delivery of commands does not make sense for case (d) - that of > creating a new session - ordering is not guaranteed anyway across > sessions. > > --=_alternative 00728C95C2256CA7_= Content-Type: text/html; charset="US-ASCII"
I am not sure a target is mandated to send a sense after the session went away!

There are few things that survive such an event.

You may want to consider the clearing effects appendix.

Julo



"Eddy Quicksall" <Eddy_Quicksall@ivivity.com>
Sent by: owner-ips@ece.cmu.edu

07/01/03 18:35
Please respond to
<Eddy_Quicksall@ivivity.com>
To
"'Mallikarjun C.'" <cbm@rose.hp.com>, <ips@ece.cmu.edu>
cc
Subject
RE: iSCSI: Implicit Termination of Tasks





I think the point is that the target must set a Sense Key/ASC/ASCQ of
06/6E/00 internally because the next command could be a Request Sense and
the target is a must to send 06/6E/00 since the previous command failed.
Also, as you pointed out, the initiator may be using ACA in which case the
ACA Active status would be sent (which lets the initiator take corrective
action to maintain ordering).

Am I correct?

Eddy

-----Original Message-----
From: Mallikarjun C. [mailto:cbm@rose.hp.com]
Sent: Monday, January 06, 2003 9:15 PM
To: Eddy_Quicksall@iVivity.com; ips@ece.cmu.edu
Subject: Re: iSCSI: Implicit Termination of Tasks


Eddy,

iSCSI's design goal was to ensure command ordering
even in the face of errors - ultimately, we wanted the SCSI
execution ordering to be correct while running on iSCSI.
This should be able to be guaranteed by the iSCSI targets,
while initiators may/may not employ command ordering.

For this to happen, iSCSI must both maintain its delivery
ordering, and require SCSI CHECK CONDITIONs to
be locally triggered on the target on iSCSI exception
conditions such as connection terminations.  The CHECK
CONDITION would then cause the ACA/persistent-UA to
be invoked if so desired by the initiator.

This is not "a method of implementing", it's required behavior
to meet iSCSI's architectural guarantee of command ordering.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm@rose.hp.com


----- Original Message -----
From: "Eddy Quicksall" <Eddy_Quicksall@iVivity.com>
To: "'Mallikarjun C.'" <cbm@rose.hp.com>; <ips@ece.cmu.edu>
Sent: Monday, January 06, 2003 12:46 PM
Subject: RE: iSCSI: Implicit Termination of Tasks


> Yes, I noticed my typo of "two" vs. "three" but too late.
>
> Below you say that the ordering is iSCSI ordering but section 6.5 is
saying
> SCSI ordering (queued commands is SCSI). So, that leaves me a little
> confused as to what this paragraph is trying to say, especially when
the
> "status is never communicated back ... to the initiator".
>
> I'm probably mis-understanding something. It appears as though this is
just
> a method of implementing within the target.
>
> Eddy
>
> -----Original Message-----
> From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> Sent: Monday, January 06, 2003 3:12 PM
> To: Eddy_Quicksall@ivivity.com; ips@ece.cmu.edu
> Subject: Re: iSCSI: Implicit Termination of Tasks
>
>
> Comments below.
> --
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions
> Hewlett-Packard MS 5668
> Roseville CA 95747
> cbm@rose.hp.com
>
> ----- Original Message -----
> From: "Eddy Quicksall" <Eddy_Quicksall@ivivity.com>
> To: <ips@ece.cmu.edu>
> Sent: Monday, January 06, 2003 5:16 AM
> Subject: iSCSI: Implicit Termination of Tasks
>
>
> > There are two sections titled Implicit Termination of Tasks but they
> are
> > slightly different. Which is correct?
>
> Both are correct and consistent.
>
> >
> > Section 6.5 lists 4 items but section 10.14.5 only lists two.
>
> I'm seeing three in 10.14.5.....
>
> Even though 6.5 lists all the four cases, it makes it clear that the
> check condition is to be employed only for three cases - and
> only those three are listed by 10.14.5.  Perhaps the text could have
> been a little bit more explicit about this distinction.
>
> >
> > If 6.5 is correct, why is item D not included in the unit attention?
> SAM-3
> > says:
>
> It's not so much a SAM issue.  The issue we considered was how to
ensure
> iSCSI-standard ordered delivery of commands in the face of errors.
The
> ordered delivery of commands does not make sense for case (d) - that
of
> creating a new session - ordering is not guaranteed anyway across
> sessions.
>
>
--=_alternative 00728C95C2256CA7_=--