Subject: iSCSI: ABORT TASK SET et al. in Drafts 16 & 17

From: "Tony Battersby" <[email-masked]>
Date: Fri, 20 Sep 2002 09:54:59 -0400

Consider the following scenario:

a) Target receives a non-immediate command with CmdSN 9
b) Target receives an immediate ABORT TASK SET with CmdSN 11
c) Target receives an immediate command with CmdSN 11
d) Target receives a non-immediate command with CmdSN 10
e) Target receives a non-immediate command with CmdSN 11

(the target could receive the commands out-of-order because they might be
sent on different connections)

For processing the ABORT TASK SET, Section 9.6.2 (Draft 17), "Task
Management Actions on Task Sets", the target:

"b) Waits for all target transfer tags to be responded to and for all
affected tasks in the task set to be received."

The set of "all affected tasks" is defined in Section 9.5.1.  Prior to Draft
16, this was:

"Task management requests must act on all the commands having a CmdSN lower
than the task management CmdSN."

Going with this definition, the target should abort the commands from steps
a) and d) but not from steps c) and e).  The target would have to wait for
and abort the non-immediate command with CmdSN 10 in step d) before
returning the Task Management Function Response.

However, later in the same paragraph (Draft 15), the set of "all affected
tasks" was re-defined as the tasks "with CmdSN not higher than the task
management command CmdSN", which is different from the first definition for
the case of tasks with CmdSN equal to the Task Management Function.  When I
asked about this discrepancy (in the message with the subject "iSCSI: Abort
Task Set CmdSN: < or <="), I was told "Abort Task Set should act only on
commands that where issued before it and immediate commands with the same
CmdSN do not meet this criteria."  This explanation worked for me, and I
assumed that the CmdSN comparison should be "<" rather than "<=".

However, in Draft 16, the text was changed to:

"Task management requests must act on all the commands having a CmdSN that
do not exceed the task management CmdSN."

I assume that this change was made along with the other changes for ABORT
TASK on immediate commands.  This change in wording may work for ABORT TASK
but it does not make sense to me for other Task Management Functions (ABORT
TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET).  To see this, consider the
same example again:

Using a "<=" comparison on CmdSN, the target would have to abort the
commands from steps a), b), d), and e).  The target would have to wait for
command e) before returning the Task Management Function Response.  Because
of the requirement for immediate commands to carry the current CmdSN value,
the initiator would have had to issue command e) _after_ the ABORT TASK SET
command.  So, the target would have to wait for and abort a command that was
issued after the ABORT TASK SET itself.

This clearly does not make sense, so I assume that the change in wording in
Draft 16 was not intended to imply a change in behavior for ABORT TASK SET
et al., correct?  Could the wording be revised to fix this?

Anthony Battersby
Cybernetics

---

From: "Julian Satran" <[email-masked]>
Date: Sun, 22 Sep 2002 15:58:50 +0300

Tony,

It is a mistake. I will fix it the first time I have a chance.

Thanks,
Julo

"Tony Battersby" <[email-masked]>
Sent by: [email-masked]
20/09/02 16:54
Please respond to tonyb

        To:     <[email-masked]>
        cc: 
        Subject:        iSCSI: ABORT TASK SET et al. in Drafts 16 & 17

The set of "all affected tasks" is defined in Section 9.5.1.  Prior to 
Draft
16, this was:

"Task management requests must act on all the commands having a CmdSN 
lower
than the task management CmdSN."

Going with this definition, the target should abort the commands from 
steps
a) and d) but not from steps c) and e).  The target would have to wait for
and abort the non-immediate command with CmdSN 10 in step d) before
returning the Task Management Function Response.

However, later in the same paragraph (Draft 15), the set of "all affected
tasks" was re-defined as the tasks "with CmdSN not higher than the task
management command CmdSN", which is different from the first definition 
for
the case of tasks with CmdSN equal to the Task Management Function.  When 
I
asked about this discrepancy (in the message with the subject "iSCSI: 
Abort
Task Set CmdSN: < or <="), I was told "Abort Task Set should act only on
commands that where issued before it and immediate commands with the same
CmdSN do not meet this criteria."  This explanation worked for me, and I
assumed that the CmdSN comparison should be "<" rather than "<=".

I assume that this change was made along with the other changes for ABORT
TASK on immediate commands.  This change in wording may work for ABORT 
TASK
but it does not make sense to me for other Task Management Functions 
(ABORT
TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET).  To see this, consider the
same example again:

Using a "<=" comparison on CmdSN, the target would have to abort the
commands from steps a), b), d), and e).  The target would have to wait for
command e) before returning the Task Management Function Response. Because
of the requirement for immediate commands to carry the current CmdSN 
value,
the initiator would have had to issue command e) _after_ the ABORT TASK 
SET
command.  So, the target would have to wait for and abort a command that 
was
issued after the ABORT TASK SET itself.

This clearly does not make sense, so I assume that the change in wording 
in
Draft 16 was not intended to imply a change in behavior for ABORT TASK SET
et al., correct?  Could the wording be revised to fix this?

Anthony Battersby
Cybernetics