Subject: RE: aborting an out of sequence cmdSN

From: [email-masked]
Date: Tue, 17 Apr 2001 03:03:08 -0400

Eddy,

> Does iSCSI have a way to abort the commands that are in the target but not
> yet in the SCSI Target Layer?

No, it doesn't.  Part of the problem is that just considering
iSCSI info, the Initiator can't tell whether such commands
are in the Target vs. still in-flight.  TCP ACK info may help,
but if TCP hasn't ACKed, the Initiator still doesn't know.

This is the issue that Doug's been posting about, advocating
that iSCSI always reject all commands prior to the task abort
on the assumption that the initiator can reissue them - given
the lack of support this has received, I'm going to take this
opportunity to state that I believe WG rough consensus exists
for NOT pursuing this "reject all prior commands" approach.
This is the last chance for anyone else to express support for
this reject-based approach.

If we were to address the original issue, I think some sort
of new mechanism is needed at the iSCSI level, as the
attempts to use a side effect of SCSI task aborts don't
seem to be getting much of anywhere (e.g., a previous
attempt at this involved having iSCSI automatically send
task management commands multiple times).  A SWAG at what
such a mechanism might look like is some sort of iSCSI
"Cancel" that names the CmdSN(s) to be cancelled and sent
in the same PDU as the SCSI Task Abort or Task Set Abort
that is supposed to abort them.  Canceling would apply
both to commands waiting for CmdSN in iSCSI as well as
those not yet received by the target (i.e., the target
has to have some notion of "pending cancel" for commands
it hasn't received yet.  The cancelled commands
probably have to return some sort of iSCSI service error
rather than SCSI sense data.  Something like this looks
like it can be made to work as desired (issue TASK 
ABORT with the corresponding Cancel for immediate delivery,
and if SCSI declares the TASK ABORT to have succeeded,
then that command will not subsequently execute), but it'll
add complexity.  Is that worth the benefit of being able
to reach out and definitively strangle an errant command?

--David

> -----Original Message-----
> From:	Eddy Quicksall [SMTP:[email-masked]]
> Sent:	Friday, April 13, 2001 6:40 PM
> To:	Ips@Ece. Cmu. Edu (E-mail)
> Subject:	aborting an out of sequence cmdSN
> 
> 
> If a command is received out of sequence, it is not passed to the SCSI
> Target Layer. So, it must be queued waiting for the prior command. Now, if
> the prior command never comes the operating system may attempt to abort
> the
> lost command by sending an abort to the driver.
> 
> The abort can't be turned into an ABORT TASK TMF because the target iSCSI
> has not acknowledged that it has received the original command yet. And,
> even if the ABORT TASK was sent, it can't get to the SCSI Target Layer
> because its cmdSN will be higher than the most recent command.
> 
> The iSCSI initiator drive could just jerk it out of its queue (knowing
> that
> it hasn't been acknowledged yet) but then the iSCSI target may still
> execute
> it when the missing PDU's arrive.
> 
> Does iSCSI have a way to abort the commands that are in the target but not
> yet in the SCSI Target Layer?
> 
> Eddy
>

---

From: Sandeep Joshi <[email-masked]>
Date: Tue, 17 Apr 2001 10:14:50 -0400

David,

The "iSCSI cancel" proposal you describe below has been presented 
once before.  If you recall, I was asking for a refCmdSN in the 
TaskMgmt PDU.  The refCmdSN would be the cmdSN of the *original*
task.   See http://ips.pdl.cs.cmu.edu/mail/msg04022.html

Your objection to this proposal then was that it did not comply 
with SAM2.  See http://ips.pdl.cs.cmu.edu/mail/msg04028.html
The only difference between that and what you now describe below 
is the addition of this concept of an "iSCSI service error" response.

We do need *some* mechanism for a deterministic abort_task.

Otherwise, initiator has to retain state to ensure that it will
process (or fail) any SCSI response or R2T PDUs which may 
come in later, since the abort_task did not deterministically
ensure that the target has deleted the original task.
(Note: somewhere in the spec, there is a statement that initiator
MUST always honour R2T...?)

The initiator state must now be retained for an iSCSI task
which has *NO* corresponding SCSI task - which gets as complicated
to cleanup as the target state which would result from a 
pending abort.  

So our options for abort_task boil down to..
(1) use connection allegiance for TASK MGMT PDU.
(2) reject all commands prior to cmdSN of TASK MGMT PDU.
(3) cmdSN of original task is sent with TASK MGMT PDU and
    target at the iSCSI layer keeps state.
(4) iSCSI initiator retains state for deleted tasks to ensure
    that R2T/Scsi Responses are appropriately handled.

-Sandeep

---

From: Santosh Rao <[email-masked]>
Date: Tue, 17 Apr 2001 16:10:17 -0700

I'd think option 1 is the simplest (with the caveat that the task mgmt
PDU referred to is the Abort Task.) and only impacts the affected
command/task.

Pierre Labat and I have asked for this 4 months ago. (See :
http://ips.pdl.cs.cmu.edu/mail/msg02958.html). The concept of connection
allegiance should be extended to include the Abort Task. Also,
connection allegiance should apply to the task (which spans multiple
commands in the case of linked commands.), allowing for a deterministic
clean up of stale PDUs of the task through the use of Abort Task.

- Santosh