iSCSI: DAP Retry comments

[Black_David@emc.com]

> T	p 103	6.1.1 Usage of Retry and 6.7 SCSI Timeouts: the semantics of
Retry
> remain broken rendering it useless for tape operation. SCSI level error
> detection and recovery is the preferred mechanism. Refer to previous
emails
> sent via the IPS reflector regarding this matter.

Can you provide more information?  Command retry *never* results in
the command executing twice - both the original command and the retry
have the same CmdSN, so the second one is dropped as a duplicate if
the first one was received correctly.  6.1.1 is very clear that retry
MUST NOT be used if the command was received successfully (acknowledged
by ExpCmdSN), and if it is used, the retried command PDU is silently
dropped.
iSCSI's ordered delivery requirement avoids the situation in which a
dropped command causes subsequent commands to mis-execute - if none
of the commands are marked for immediate delivery, iSCSI will stop
at the "hole" created by the dropped command, and wait for the retry
to plug the hole.  

> T	p 128	8.6 Considerations for State-dependent devices: last
paragraph:
> don't agree with the statement that error recovery at the iSCSI level
> (specifically Retry in its current state) is advisable. Retry at the SCSI
> level is feasible and is not difficult (i.e., READ POSITION and LOCATE
> commands). This paragraph should be removed.

Two questions:
- What about the SNACK and allegiance change mechanisms?
- What about the "legacy" tape devices (e.g., as discussed in London)
	that presumably don't implement those commands?  I believe this
	text was originally intended to address this class of devices.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------