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

From: "Julian Satran" <[email-masked]>
Date: Fri, 30 Aug 2002 21:15:23 +0300

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: Fri, 30 Aug 2002 14:29:43 -0400

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

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

If the target either:

...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.

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

This is for consistency with another sentence earlier in the same paragraph.

Anthony J. Battersby
Cybernetics

---

From: "Julian Satran \(Actcom\)" <[email-masked]>
Date: Sat, 31 Aug 2002 02:21:58 +0300

Immediate commands do not create holes. Immediate commands can be aborted ONLY if referenced by their ITT.
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
  ----- 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 

                To:        <[email-masked]> 
                cc:         

  If the target either:

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

  Anthony J. Battersby
  Cybernetics