Subject: Re: iSCSI: abort task & abort task set

From: "Julian Satran" <[email-masked]>
Date: Mon, 3 Dec 2001 14:31:16 +0200

Mallikarjun,

Comments in text - Julo

PS - I would like also to point out that we may want to consider a very 
simple alternative to the barrier scheme outlined in 9.4
- that will require less cooperation between initiator and will be simpler 
to read and implement.
I will outline such a scheme soon.

"Mallikarjun C." <[email-masked]>
Sent by: [email-masked]
12/03/2001 01:33 AM

        To:     "ips" <[email-masked]>
        cc: 
        Subject:        iSCSI: abort task & abort task set

Julian,

iSCSI currently requires two responses to be returned for an aborted task 
-
one for the original task with a "good" status, and the second for the 
task
management function (TMF) itself.  So, the following legal behaviors are
required of a target -
    a) plug the CmdSN gap if the command was not received,
    b) send a SCSI response and TMF response if the task still is active,
    c) send a TMF response if the task isn't active (if already complete).

I would like to suggest that we reconsider our approach for case (b) for
 a variety of reasons, to change it to:
    b) send a TMF response signalling that the abort is complete, if the
task
        still is active.

Here are my reasons -

    1. Target iSCSI layer would need to make a SCSI response up on
        an abort of an active task.  It then follows that the iSCSI layer
        may have to make up several SCSI responses on an 'abort task set'.

   2.  The current approach also creates a side effect that isn't readily
        apparent for 'abort task set'.  Initiators would need to stall
processing
        'abort task set' TMF response till task responses (to account for
all
        the tasks in the task set) on multiple TCP connections (possibly 
on
        different NICs) are received - which I am afraid would tantamount 
to
        an initiator scoreboard.
+++ That is not entirely correct. The whole purpose of requiring the 
target to send a "good status" is to allow the initiator to send the 
response immediately and have the initiator mark its internal data 
structures as aborted - but avoid reusing ITT untill it gets the good 
answer.
This way initiator can make progress and it can be sure that it won't be 
surprised by an "old" answer after it has reused the ITT
+++
    3. The current approach complicates initiator implementations that 
want
        to process a successful SCSI completion even after they initiated
        timeout processing since on an 'abort task set', initiators can
never
        be sure if the response was pre-abort, or post-abort (made up 
"good"
        status).  I believe it is worth preserving this implementation
choice.
+++ see above +++
   4.  I am further concerned that iSCSI is possibly in violation of the
spirit of
        SAM-2, rev20.
         - clause 5.6.2 that states -
"When an initiator causes its own task(s) to be aborted, no notification
that the task(s) have been aborted shall be
returned to the initiator other than the completion response for the 
command
or task management function action
that caused the task(s) to be aborted and notification(s) associated with
related effects of the action (e.g., a target
reset unit attention condition)."
+++ I did say explicitly that the good status is a "good-will" message 
between iSCSI target and initiator. It does not have to reach SCSI. SAM 
also allows statuses that have been sent before an abort was executed but 
received after the TM response to be delivered or not at initiators will 
+++
         - clause 5.3.1 that states -
"GOOD. This status indicates that the device server has successfully
completed the task."

I propose that the target deliver only the TMF response on an abort of
an active task on an 'abort task' TMF, and not transmit an 'abort task 
set'
TMF response until all the current StatSN's on all connections (as on the
completion of "abort task set') in the session are ack'ed.  This ack may 
be
solicited by way of a NOP-IN with valid TTT.

+++ that may result in an initiator reusing prematurely an ITT and being 
hit by a late arriving status
for a "former" task - i.e. non-deterministic behavior +++
 
This gives the determinism to initiators that  (a) abort task set TMF
response
signifies that the entire task set had been dealt with, and (b) every task
response
is a true SCSI end-to-end reponse (not generated by iSCSI), besides doing
away with SCSI-response code in the target iSCSI layer.

Comments?  Did I miss any corner cases?

+++ see above +++

Regards.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668
Roseville CA 95747

---

From: "Mallikarjun C." <[email-masked]>
Date: Mon, 03 Dec 2001 09:53:58 -0800

Resolution of this certainly requires an offline discussion -
which we two plan to have.  But one comment to make my proposal
clear to the list.

> completion of "abort task set') in the session are ack'ed.  This ack
> may be
> +++ that may result in an initiator reusing prematurely an ITT and
> being hit by a late arriving status

That is not possible since as I said above, the 'abort task set'
TMF response is sent only after all StatSN "snapshots" are ack'ed 
on all connections.
--
Mallikarjun

Mallikarjun Chadalapaka

Julian Satran wrote:
> 
> Mallikarjun,
> 
> Comments in text - Julo
> 
> PS - I would like also to point out that we may want to consider a
> very simple alternative to the barrier scheme outlined in 9.4
> - that will require less cooperation between initiator and will be
> simpler to read and implement.
>   "Mallikarjun C."
>   <[email-masked]>                       To:        "ips"
>   Sent by: [email-masked]  <[email-masked]>
>                                           cc:
>   12/03/2001 01:33 AM                     Subject:        iSCSI:
>                                   abort task & abort task set
> 
> 
> 
> Julian,
> 
> iSCSI currently requires two responses to be returned for an aborted
> task -
>        the tasks in the task set) on multiple TCP connections
> (possibly on
>        different NICs) are received - which I am afraid would
> tantamount to
>        an initiator scoreboard.
> This way initiator can make progress and it can be sure that it won't
> be surprised by an "old" answer after it has reused the ITT
> +++
> between iSCSI target and initiator. It does not have to reach SCSI.
> SAM also allows statuses that have been sent before an abort was
> executed but received after the TM response to be delivered or not at
> initiators will +++
> completion of "abort task set') in the session are ack'ed.  This ack
> may be
> +++ that may result in an initiator reusing prematurely an ITT and
> being hit by a late arriving status

---

From: Patrick Stirling <[email-masked]>
Date: Tue, 4 Dec 2001 05:12:40 +0530 (IST)

I've been lurking silently on this list for a while, but would like to
throw in my opinion here!

I agree with Mallikarjun's proposal that the iSCSI target layer should not
send responses for individual commands on receiving an Abort Task Set task
mgmt command. I think it breaks the layering (command responses should be
end to end).

Julo commented:

> +++ The whole purpose of requiring the target to send a "good status"
> is to allow the initiator to send the response immediately and have
> the initiator mark its internal data structures as aborted - but avoid
> reusing ITT untill it gets the good answer.  This way initiator can
> make progress and it can be sure that it won't be surprised by an
> "old" answer after it has reused the ITT +++

Perhaps I'm missing something here - when would the initiator send a
response to the target? Surely the Abort is intended to kill the command
immediately.

Secondly, the initiator should not reuse task tags until it knows the
status of the previous command - and it can't know this until the target
responds to the TMF. With a 32 bit task tag I don't see a problem with
running out of tag values!

So the requirement is that the target abort all commands with a SN less
than that of the TMF itself, then respond to the TMF. Receipt of the TMF
response indicates that the initiator can clean up for all aborted
commands. I don't see that it's an undue burden on the initiator to retain
the per-command information until then.

As an editorial aside, I find ACA and TMF very confusing - anything we can
do to simplify them is good!

patrick
Patrick Stirling
VERITAS Software Corp.