RE: iscsi: rev 05 2.5.1 requires ACA support

[Black_David@emc.com]

Considering Charles's first two problems:

> - problem 1) When an initiator's I/Os are cleared by it own actions (e.g.
> sending a task management function of abort task set) how does it know
which
> of issued commands were aborted and which were still in-flight and had not
> yet made it to the target.

Ordered delivery solves this one, but can cause:

> - problem 2) (closely related to 1)  How are task management functions
> delivered - with the immediate delivery option (CmdSN=0) or not?
(reference
> 1.2.2.1, top of page 12)  If immediate, then problem 1 is aggravated if
> multiple connections are used.  If not immediate, then we can have a
problem
> with the task management function never being delivered because the I/O we
> are trying to abort never made it to the target and the target's iSCSI
layer
> wont' pass up the task management function because the CmdSN number is
> wrong.

And this could be even worse if the I/O to be aborted made it to the target,
but some other I/O is stuck in a connection and hence holding up the task
management function, even though one or more commands to be aborted
are merrily executing.

> + solution to 1 and 2) I propose all task management functions be required
> to use the  following:
>   - immediate delivery option
> 
>   - utilize a new task management function sequence number field (call it
> TskMgmtSN)
> 
>   - all task management functions shall be sent on all active connections
> with the same value for TskMgmtSN
> 
>   - the target must receive the same task management function (identified
by
> TskMgmtSN) on all active connections before it acts on it.  (Use a timer
> (TBD) to weed out and close down defective connections.)

The target still has to receive the task management
command on the slow connection, or time out and close
the slow connection before it can execute the task
management command.  This is vulnerable to the
"arbitrary delay by some unrelated command" version
of problem 2).

If both problems need to be solved, the task management
command may have to be sent at least twice when there
are multiple connections active:
- With immediate delivery to take effect as soon as
	possible.
- With ordered delivery to ensure that everything it
	is supposed to affect has made it to the target.

My reaction to this entire area that having iSCSI do
any duplication of task management commands
transparently to SCSI is introducing a bunch of extra
complexity that doesn't seem to deliver a lot of
extra value.  Any user of iSCSI already has to decide
between immediate and ordered delivery, and the
less we muck with the task management commands,
the more likely the user will be able to obtain
desired/expected/understood behavior.

Comments?
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------