RE: iSCSI & Linked Commands

[Robert Snively <rsnively@Brocade.COM>]

Folks,

There are no implementation problems with linked commands other than
the fact that nobody has really found a good use for them outside
a few specialized environments.  It is for that reason that they
are relatively rarely called upon, but strongly defended by their
few users.

This thread has created a significant amount of unclarity.

First:

	A task includes all commands executed in a single
	link.  It has the same Exchange identifier for all 
	steps in executing a command.  That takes care of the
	concerns expressed by Santosh.

Second:

	A set of linked commands is executed in order, by
	definition, but their ordering with respect to other
	tasks from the same or other initiators is not defined
	except through the ordinary command ordering stuff.
	The task ordering applies to the entire task, although
	this is not as explicitly defined in SAM as would be
	desirable.  This eliminates them as being tremendously
	useful in ordered execution.

Third:

	I am not aware of any usage of commands using relative
	addressing.  They are denigrated in all profiles.  They
	are a historic anomaly dating back to when SCSI was thought
	of as a total replacement for the IBM OEM channel.
	Relative addressing is defined for disk devices only,
	not sequential devices.  Sequential devices use the 
	more traditional space, skip, and locate commands.
	This eliminates relative addressing for linked commands as
	being useful to sequential devices.

Fourth:

	Stale PDUs are a fact of life in any stream of data that
	is not acknowledged and sequenced on a PDU by PDU basis.
	Both Fibre Channel and iSCSI have to deal with that.
	Fibre Channel has a function called "recovery qualifier"
	that automatically discards stale PDUs.  It has an additional
	function called R_A_TOV which guarantees that stale PDUs
	will not appear later than a certain time.  With those two
	mechanisms, stale PDUs become a non-problem.  In FCP,
	an additional mechanism is provided to handle the stale
	PDUs created by Abort Task actions.

	One way or another, iSCSI will have to deal with the same
	problem.

Notes of possible interest:

Command linking is an anachronism.  It has been used by a few
devices that think of themselves as having IBM OEM channel-like
characteristics, where a list of commands is the normal I/O
execution unit.  It was also used by Sun Microsystems in early
SCSI implementations that used software selection algorithms that
were so high in overhead that command linking provided improved
performance.  Aside from those cases that have been listed here
(AS400 and some Unisys systems), command linking is not in modern
use as far as I know.  Command queuing and buffering have provided
performance improvements that are so notable that command linking
has fallen aside.