Subject: [Ips] iSCSI: Followup to TMFs/iSCSI Cross Nexus requirement

From: "Pittman, Joseph" <[email-masked]>
Date: Thu, 10 Nov 2005 11:02:57 -0500

One followup to my earlier message:
 
> 3) Both the iSCSI spec and the iSCSI Implementer's Guide state the
>    following:
> 
>      If some tasks originate from non-iSCSI I_T_L nexuses then the
>      means by which the target insures that all affected tasks have
>      returned their status to the initiator are defined by the
>      specific non-iSCSI transport protocol(s).
> 
>    By my reading, the text is clearly requiring that the target
>    make certain that the initiator has RECEIVED the responses,
>    REGARDLESS of the transport protocol.  Thus the iSCSI spec is
>    imposing additional requirements on other transport protocols,
>    requirements beyond those imposed by the SCSI protocols themselves.
>    It is clearly beyond the scope of one transport protocol to impose
>    requirements on other transports.

In an earlier discussion of this issue, the following opinions
or rationales were stated:
 
1) The requirement need not apply to non-iSCSI nexuses (Mallikarjun
   and Julian)
2) The requirement is imposed for SAM reasons, not for iSCSI-specific
   reasons (Mallikarjun)
 
It seems to me that, if the requirement is imposed for SAM reasons,
then
 - it would have been imposed by SAM itself
 - it would be a transport-independent requirement, and would thus
   have to apply to all transports
 
If the requirement does not apply to non-iSCSI nexuses, then it
cannot be necessary for correct operation.
 
What am I missing?
 
--
Joe Pittman
[email-masked]

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 10 Nov 2005 09:35:36 -0800 (PST)

Hi Joe,

Have you had a chance to review the fast multi-task
abort TMF model I proposed last week?  The proposal
should address your concerns.  I would appreciate your
review feedback on that.

Mallikarjun

--- "Pittman, Joseph" <[email-masked]>

> https://www1.ietf.org/mailman/listinfo/ips

		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

---

From: Julian Satran <[email-masked]>
Date: Sun, 13 Nov 2005 09:48:15 +0200

Joseph,

Since timing on different I_T nexii is "unrelated" I guess that the rule 
about making sure that all preceding statuses have been received before 
giving the response to the abort/clear task set command that cause the 
"multi-nexi" effect applies only to one nexi the originating (all the 
others are required to some other report form by SAM- TASK ABORTED or TASK 
CLEARED BY ANOTHER INITIATOR).
However the last paragraph of SAM2 - 5.7.3 - require some ordering (still 
puzling to me) between completing those tasks and entering new tasks in 
the command set.
Since the command set in those cases is a "multi-initiator" command set 
the meanings by which that sequencing can be achieved are unclear 
(provided it can be achieved).
That drove us to suggest ordering by the target.

The murkiness of the paragraph you refer too is a direct result of the SAM 
murkiness.  All SCSI transports besides SCSI are serializing - and in the 
absence of failures they will behave as expected. 

I am also not sure that before iSCSI a target supporting different nexi 
using different transports has been considered - but SAM does not exclude 
it either.

---

From: William Studenmund <[email-masked]>
Date: Mon, 14 Nov 2005 11:26:31 -0800

On Nov 12, 2005, at 11:48 PM, Julian Satran wrote:

> Joseph,
>
> Since timing on different I_T nexii is "unrelated" I guess that the 
> rule about making sure that all preceding statuses have been received 
> before giving the response to the abort/clear task set command that 
> cause the "multi-nexi" effect applies only to one nexi the originating 
> (all the others are required to some other report form by SAM- TASK 
> ABORTED or TASK CLEARED BY ANOTHER INITIATOR).
> However the last paragraph of SAM2 - 5.7.3 - require some ordering 
> (still puzling to me) between completing those tasks and entering new 
> tasks in  the command set.
> Since the command set in those cases is a "multi-initiator" command 
> set the meanings by which that sequencing can be achieved are unclear 

Ok! We now have a reference as to what the SAM concerns are (regardless 
of what we think of them :-)

Here's the SAM 2 text for section 5.7.3:

----- Begin copied text -----
When a SCSI initiator port causes the task(s) of another SCSI initiator 
port to be aborted, the other SCSI initiator port shall be notified 
that the task(s) have been aborted. The method of notification shall 
depend on the setting of the TAS bit in the Control mode page (see 
SPC-2) that applies to the other SCSI initiator port.

If the TAS bit is set to zero, the method of notification shall be an 
unit attention condition. The additional sense code set for the unit 
attention condition depends on the action that caused the task(s) to be 
aborted.

If the TAS bit is set to one, the method of notification shall be the 
termination of each aborted task with a TASK ABORTED status. The 
COMMANDS CLEARED BY ANOTHER INITIATOR unit attention condition shall 
not be established, however, the establishment of any other applicable 
unit attention condition shall not be affected.

When a logical unit is aborting one or more tasks from a SCSI initiator 
port with the TASK ABORTED status it should complete all of those tasks 
before entering additional tasks from that SCSI initiator port into the 
task set.
-----  End copied text  -----

SAM 4 contains almost identical text except that it uses "I_T nexus" 
instead of "SCSI initiator port."

> The murkiness of the paragraph you refer too is a direct result of the 
> SAM murkiness.  All SCSI transports besides SCSI are serializing - and 
> in the absence of failures they will behave as expected.

Hmmm.. Now we dive into the realm of interpretation. :-)

My read on that text is that the last paragraph applies to the TAS 1 
case. Further, my understanding is that it means that we go through the 
following chain of states: Tasks are in the task set => All tasks in 
the task set are aborted => New tasks are allowed to enter the task 
set. i.e. to the extent that aborting all tasks in the task set takes 
time, no other tasks will enter the task set while it happens.

To be honest, I don't see any requirement that the TMF which causes the 
abort has to wait on the abort processing on other I_T nexuses. I agree 
the TMF should wait for all impacted tasks to START abort processing, 
but I don't see that we need to wait for it to finish.

Waiting for other sessions to finish any form of processing is my 
biggest concern with how we handle aborts.

Take care,

Bill

---

From: Julian Satran <[email-masked]>
Date: Tue, 15 Nov 2005 11:29:27 +0200

in text ...

William Studenmund <[email-masked]> wrote on 14-11-2005 

> biggest concern with how we handle aborts.

Joseph concern (as I read it) was related to waiting for status ack on 
other nexi before handing the initiator the response to the TM command.
This is not required by iSCSI.
However it is required that all the tasks that have been issued after the 
TM response (as the initiators might be indirectly aware of this event) 
must be accepted - and the ways by which they will ascertain that this 
happens and is not disruptive is protocol dependent.

It just occured to me that a "litmus test" of functional corectness would 
be to assume the a non-iSCSI initiator issues a clear task-set TM command 
and the "other" nexus is an iSCSI nexus.

> Bill
> [attachment "PGP.sig" deleted by Julian Satran/Haifa/IBM]

---

From: William Studenmund <[email-masked]>
Date: Tue, 15 Nov 2005 10:06:44 -0800

>  > ----- Begin copied text -----

[snip]

> This is not required by iSCSI.

My understanding of this whole discussion is that we were talking about 
having the implementer's guide require it. Thus while not in 3720, it 
is a current concern. :-)

> However it is required that all the tasks that have been issued after 
> the TM response (as the initiators might be indirectly aware of this 
> event) must be accepted - and the ways by which they will ascertain 
> that this happens and is not disruptive is protocol dependent.
>
> It just occured to me that a "litmus test" of functional corectness 
> would be to assume the a non-iSCSI initiator issues a clear task-set 
> TM command and the "other" nexus is an iSCSI nexus.

Sounds like a good test.

Take care,

Bill

---

From: William Studenmund <[email-masked]>
Date: Tue, 15 Nov 2005 10:28:48 -0800

> This is not required by iSCSI.

Actually, I was just re-reading the Abort Task Set and Clear Task Set 
text, and the status ack requirement is in RFC 3720. It's in section 
10.6.2 on page 136, in step d) of the "The target:" events section:

          d) Takes note of last-sent StatSN on each of the connections in
             the iSCSI sessions (one or more) sharing the affected task
             set, and waits for acknowledgement of each StatSN (may
             solicit for acknowledgement by way of a NOP-In).  If some
             tasks originate from non-iSCSI I_T_L nexi then the means by
             which the target insures that all affected tasks have
             returned their status to the initiator are defined by the
             specific protocol.

So the concern Joseph has (which I also have as best I understand 
everyone's position) does apply to RFC 3720. :-|

Take care,

Bill

---

From: Julian Satran <[email-masked]>
Date: Sun, 20 Nov 2005 02:58:57 +0200

You are right and we have to fix this somewhere (errata is probably the 
legal best). Julo

William Studenmund <[email-masked]> 
Sent by: [email-masked]
15-11-05 13:28

To
Julian Satran/Haifa/IBM@IBMIL
cc
[email-masked], "Pittman, Joseph" <[email-masked]>
Subject
Re: [Ips] iSCSI: Followup to TMFs/iSCSI Cross Nexus requirement

Take care,

Bill