Subject: RE: iSCSI: DataRN

From: [email-masked]
Date: Mon, 22 Jan 2001 10:55:16 -0500

> The iSCSI draft should refrain from advocating any retry policies at the
> iSCSI layer, such as being currently done for connection failures and
> digest errors.

If the above had said "at the SCSI layer", I'd agree.  The issue being
addressed here is hiding failure of a connection in an iSCSI session from
SCSI (i.e., transparently recover at the iSCSI layer from failure of an
iSCSI
connection). The following discussion of retry is correct for SCSI, but
doesn't
apply to iSCSI because iSCSI will deliver the retried command to the SCSI
layer at the device at most once, and hence the described problem caused
by the command being executed at the device twice can't happen.

> I/O retry policies are decided by the SCSI ULP based on the class of the
> target. (disk, tape, changer, etc).
> For a tape class of device, the SCSI ULP may not wish to retry on an error
> [without a prior rewind operation]. In such situations, iSCSI attempting
to
> retry on connection failures or digest errors can result in problems with
> sequential access type of media.

OTOH, I'm sympathetic to the argument that it's up to an iSCSI
implementation
to decide how aggressively to recover a failed connection - notice that SCSI
works quite happily over Fibre Channel where any individual command can be
dropped without losing the session, and there's no retry (although FCP-2 has
had to do some things for tape).  The mechanisms needed for transparent
recovery should be documented, and then we can figure out if they are MUST,
SHOULD, or MAY implement.  Getting back to the original point - the reason
for
dropping DataRN is that the gain from the optimization it provides for this
sort
of recovery situation doesn't seem to justify the added complexity.

--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: Mon, 22 Jan 2001 09:20:24 -0800 (PST)

> by the command being executed at the device twice can't happen.

David,

The above is correct if the digest error or connection failure occurred on
delivery of the command. If a digest error were to be detected by an
initiator on the response PDU (by which time the target has already
completed the operation and the TCP layer at the initiator has already
sent the ACK), then, the command is complete from the device perspective
and should not be retried. 

Similarly, if the command had completed at the target and the Response PDU
in transit was affected by a connection failure, retries should not be 
performed by the initiator. 

Rather than distingush these corner cases in its retry policies, 
iSCSI should refrain from advocating retries at its layer. 
Connection failures can be considered as a gross error and recovery can 
be performed at the SCSI ULP.

Regards,
Santosh

-- 
#################################
Santosh Rao
Software Design Engineer,
HP, Cupertino.
email : [email-masked]
Phone : 408-447-3751
#################################