Subject: RE: iSCSI ABORT TASK RefCmdSN question

From: [email-masked]
Date: Fri, 30 Aug 2002 10:15:55 -0400

> Suppose an iSCSI target receives an ABORT TASK Task Management Function
that
> does not refer to a valid task (i.e. the Referenced Task Tag does not
match
> any task at the target) but the CmdSN is inside the valid window and
matches
> a non-immediate command that has not yet been delivered for execution.
For
> example,
> 
> Target's ExpCmdSN is 10.
> Target has a queued non-immediate command with CmdSN 11 and 
> Initiator Task Tag of 55 which has not been delivered for execution
> because the target is waiting for a non-immediate command with CmdSN 10
> first.  Target receives an immediate ABORT TASK Task Management Function
> with Referenced Task Tag of 66 and RefCmdSN of 11.

This is an error.  The initiator has violated the following MUST:

9.5.5  RefCmdSN

   For the ABORT TASK function, initiators MUST always set this to the 
   CmdSN of the task identified by the Referenced Task Tag field. Tar-
   gets must use this field as described in section 9.6.1 when the task 
   identified by the Referenced Task Tag field is not with the target.

A Reject PDU with Reason 0x09 will do nicely to tell the Initiator that
it screwed up.  Processing an erroneous task management function
request by trying to infer what the initiator might have intended is
not a good idea.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: "Tony Battersby" <[email-masked]>
Date: Fri, 30 Aug 2002 13:16:36 -0400

It seems that an initiator attempting to abort an immediate command may
inadvertently cause the next non-immediate command to be aborted instead.
For example,

Initiator sends an immediate command "A" with CmdSN 10.
Initiator sends a non-immediate command "B" with CmdSN 10.
Initiator sends an immediate ABORT TASK command "C" with CmdSN 11 to abort
command "A" (RefCmdSN == 10, Referenced Task Tag == Initiator Task Tag of
"A").

If the target either:
1) Receives "C" before "A" or "B", OR
2) Receives "C" before "B" but after executing and freeing "A",

...then the target will not have a matching task for the abort in its queue,
and will consider CmdSN 10 received because it is inside the valid CmdSN
window.  If the target then receives "B", it will silently ignore the
command because it is outside the valid CmdSN window.  This is obviously not
what the initiator was trying to accomplish.

This problem could be solved by adding a flag to the PDU for the ABORT TASK
command to indicate if the task to be aborted is immediate or non-immediate.
If the target does not have a matching task and the RefCmdSN is inside the
valid command window, then the target should consider the CmdSN received
only if the flag indicates that the task to be aborted is non-immediate.

-----------------------

One other thing: for draft 16, I recommend that the the following phrase:
"... (i.e., with CmdSN not higher than the task management command CmdSN)
..."
in section 9.5.1 be changed to:
"... (i.e., with CmdSN lower than the task management command CmdSN) ...".
This is for consistency with another sentence earlier in the same paragraph.

Anthony J. Battersby
Cybernetics