Subject: RE: iSCSI: aborting an immediate command with ABORT TASK

From: "Tony Battersby" <[email-masked]>
Date: Tue, 3 Sep 2002 13:42:38 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Julian Satran (Actcom)
Sent: Friday, August 30, 2002 7:22 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: iSCSI: aborting an immediate command with ABORT TASK

> Immediate commands do not create holes.

True.

> Immediate commands can be aborted ONLY if referenced by their ITT.

Immediate commands are uniquely identified by their ITT, not their CmdSN.
So yes, an existing immediate command at the target can be aborted ONLY if
the ITT matches the Referenced Task Tag.

>Again RefCmdSN is used only if the command is not found by ITT - and then
only to avoid having to send a duplicate command.
> Julo

It seems that the implicit assumption that you are making and I am not is
that the target will always find a command with ITT equal to the Referenced
Task Tag when the initiator attempts to abort an immediate command.  It
follows that if this were the case, then the target would never use the
RefCmdSN improperly.  However, I do not see any mechanism that guarantees
this assumption, especially given the following three observations:

1) The possible out-of-order arrival of an abort and the immediate command
upon which it is supposed to act
2) The race between an immediate command finishing normally (causing the
target to free the command and forget its associated ITT) and the initiator
aborting it
3) The immediate command to be aborted may have been discarded due to a
header digest error

In the examples I gave previously, there are several specific situations in
which the assumption does not hold, leading to incorrect behavior of the
target.

Tony
    ----- Original Message -----
    From: Tony Battersby
    To: 'Julian Satran'
    Cc: [email-masked]
    Sent: 30 August, 2002 21:29
    Subject: RE: iSCSI: aborting an immediate command with ABORT TASK

    In my example, the command with the Initiator Task Tag matching the
Referenced Task Tag is not at the target.  When the target considers the
command with RefCmdSN received, it assumes _incorrectly_ that the command
with RefCmdSN must have Initiator Task Tag == Referenced Task Tag.  That
assumption can be incorrect when immediate commands are used because
multiple commands with different Initiator Task Tags can have the same
CmdSN.  This is just another way of looking at the problem, but the problem
still exists.

      -----Original Message-----
    From: Julian Satran [mailto:[email-masked]]
    Sent: Friday, August 30, 2002 2:15 PM
    To: [email-masked]
    Cc: [email-masked]; [email-masked]
    Subject: Re: iSCSI: aborting an immediate command with ABORT TASK

    Tony,

    As it was already pointed out CmSN is a SECONDARY identifier - the
primary being the Referenced Task Tag.
    I was introduced to simplify handling holes (commands discarded or
arriving late).
    In your example A and B have different ITT or one of them gets bumped.

    Julo

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

                  To:        <[email-masked]>
                  cc:
                  Subject:        iSCSI: aborting an immediate command with
ABORT TASK

    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

---

From: "Tony Battersby" <[email-masked]>
Date: Tue, 3 Sep 2002 16:48:52 -0400

> 1) The possible out-of-order arrival of an abort and the immediate command
upon which
> it is supposed to act
target
> to free the command and forget its associated ITT) and the initiator
aborting it
> 3) The immediate command to be aborted may have been discarded due to a
header digest
> error

Replying to myself, #1 should actually not happen because of the requirement
for an ABORT TASK to be issued on the same connection to which the task
being acted upon is currently allegiant.  Points #2 and #3 are still valid
though.  Another possibility is that the target is in the process of sending
a Reject PDU for the immediate command to be aborted when it receives the
ABORT TASK command, and the target implementation doesn't check the ITT from
a PDU that it has chosen to reject.

Tony