RE: iscsi: rev 05 2.5.1 requires ACA support

["Charles Binford" <Charles.Binford@BlueSpruceNet.com>]

David,  I interpreted Doug's idea different.  I heard him saying we should
give the task management function a sequence number, but the targets iSCSI
layer pass it up as if it were immediate.  Additionally, the iSCSI layer
would be aware of, and watch for late coming I/Os on other connections using
the knowledge of the CmdSN in the task management function.

This idea can only work if the iSCSI layer is knowledgeable of the semantics
of the task management function and has enough smarts to evaluate whether or
not the late comer was effected by the task management function.  I believe
this puts more intelligence at the iSCSI layer than is necessary.

I also don't think the iSCSI layer on the initiator side should/can have the
intelligence to know whether a given task management function should be
delivered with or without the immediate option as defined today.

The prompt delivery, yet correct ordering of task management functions is a
problem specifically tied to the way we have architected iSCSI with the
multiple connections under one session.  I believe the iSCSI should be
responsible for solving this problem without any help knowledge from layers
above.

In response to my proposal to send the task management function on all
connections to solve this problem, David Black had the response below (in
another email, but copied here).  My responses are in-line, marked with
[cb].

====From David Black========
	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).

[cb] I propose we have a relatively short timer defined for this.  The
target starts it as soon as it receives the first task management function.
This puts a known upper bound on the problem. [cb]

	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.

[cb]I agree, we don't want the iSCSI layer to duplicate task management
commands as suggested here.  That is not what I'm proposing.  I'm saying
send the task management function down all connections to synchronize the
session, but the target SCSI layer only sees a single task movement
function. [cb]

      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.

[cb] Regardless of whether or not commands are being sent with ordered or
immediate delivery we still have the problem of the task management function
delivery.  You need to know for sure which issued commands were caught by
the task management function, yet you can't wait for an *unspecified* timer
to pop on a slow connection. [cb]


Charles Binford
Blue Spruce Networks
office: (316) 315-0382 / cell: (316) 210-6404
e-fax: (509) 756-4425




-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Black_David@emc.com
Sent: Saturday, March 17, 2001 6:40 PM
To: dotis@sanlight.net; ips@ece.cmu.edu
Subject: RE: iscsi: rev 05 2.5.1 requires ACA support


> Even with management commands, position within the command stream is
> assumed.  Should there be commands sent without an ability to verify
> relative position and with the potential for excessive skews between
> connections, the use of a zero seems clumsy.  It could apply to command
not
> yet received on different connections.  Even though a command may have a
> sequence value, it could be 'Marked' for immediate use without strict
> adherence to sequence.  The sequence value could be used to filter late
> comers, perhaps the cause for the management command in the first place.
> The task attribute could be used to understand if there is a need for
> immediate application or an iSCSI specific bit if that is too difficult.

This sounds like what ordered delivery is currently specified to do,
possibly
coupled with a note to implementers suggesting that task management
commands be executed promptly after delivery to SCSI.  An example of
a scenario that may work with immediate delivery ("use of a zero" above)
is one in which some person or piece of software has determined or
suspects that something undesirable is going on in/at the target device
and wants it stopped NOW!!! (e.g., "What on earth is that tape robot
doing???").

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