Subject: iSCSI: retries and SCSI

From: [email-masked]
Date: Thu, 25 Jan 2001 10:34:19 -0500

If one thinks about retries wrt layering, the iSCSI
notion of retry is at the iSCSI layer and hence is aimed
primarily at causing the target to retransmit stuff
(data, responses) that didn't make it to the initiator
previously for some reason (e.g., connection or CRC
failure).  That's an architectural purist viewpoint
that views an iSCSI retry as being about iSCSI, not
SCSI, and hence about having the target retransmit
iSCSI stuff that it's retained, as opposed to re-
executing SCSI operations.

A practical engineering viewpoint then notices that if
the SCSI operation is idempotent (doing it over has no
ill effects - generally the case for disk operations),
then a target that has not retained the stuff required
to respond to a retry could re-execute the operation as
opposed to failing the retry.  The motivation for doing
this is that an iSCSI recovery on the initiator side
should in general be cheaper (time/resources) than a
SCSI recovery.  When the operation is not idempotent
(doing it over has ill effects - tape reads and writes
are examples), then this optimization is not applicable
and if the target hasn't retained the stuff required
to respond to the retry, it has to fail/reject the retry.

This is among the topics that should be explained in the
more detailed description of error recovery that was
recognized as needed in the draft as part of the Orlando
meeting.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: Santosh Rao <[email-masked]>
Date: Thu, 25 Jan 2001 11:53:30 -0800

[email-masked] wrote:

> When the operation is not idempotent

David,

Thanks for the clarification on this. This approach of
rejecting the retry, rather than not retrying for sequential
devices, poses a couple of problems :

a) The responsibility of dealing with the reject will lie
    with a iSCSI-pSCSI or iSCSI-FC bridge in most of
    the tape connectivity cases.

b) The target iSCSI layer now needs to share SCSI state
     information with its ULP on the device's class and abilities.
     (something that would normally be exchanged b/n the peer
      SCSI ULPs on either side.)

I believe the draft already intends to address the issue of retries
on a connection failure being made optional
[if the initiator detects ULP timeout and wishes not to retry].

I would like to suggest that the same policy be applied to digest
errors as well. (as initiators may not wish to retry on a digest error,
when it sees a ULP timeout.).
This allows initiators the flexibility to not retry the I/O to
non-idempotent target media.

Thanks & Regards,
Santosh