Subject: Re: iSCSI : Bridging missing CmdSNs and Abort I/O Error recovery

From: [email-masked]
Date: Fri, 26 Jan 2001 18:00:13 +0200

Santosh,

You had a possible answer from Matt.  However I agree that we might want to
address this in text although
a solution similar to that suggested by Matt should be by now obvious to
every implementer - the target should leave a placeholder in the input
queue until the command after gets delivered.

Julo

Santosh Rao <[email-masked]> on 25/01/2001 21:38:04

Please respond to Santosh Rao <[email-masked]>

To:   IPS Reflector <[email-masked]>
cc:
Subject:  iSCSI : Bridging missing CmdSNs and Abort I/O Error recovery

Julian & All,

The draft is currently lacking a section that addresses abort I/O error
recovery. Specifically, how is CmdSN bridging issues to be handled in
the case where an initiator chooses not to retry an I/O [that failed on
a connection failure that affects the delivery of the command to the
target or a digest error at the target] because its ULP timer may have
expired.

In such cases, the initiator can send an Abort Task to inform the target
that the I.T.T is being aborted and its corresponding CmdSN can be
bridged, instead of having the target stall infinitely in its attempt to
enforce ordering and await the missing CmdSN [which is'nt going to
arrive, because the initiator did not retry the command].

Regards,
Santosh

 - santoshr.vcf

---

From: Santosh Rao <[email-masked]>
Date: Sat, 27 Jan 2001 18:22:12 -0800

Julian,

2 issues are worth addressing in the I/O Error recovery descriptions :

1) How I/O error recovery is performed on a SCSI ULP timeout
detected by the initiator. Section 9 of the FC-PLDA document
is a good example of the type of error recovery description that
would be helpful.

I'm assuming that iSCSI expects initiators to use the Abort Task
or a higher level error recovery mechanism on a ULP timeout.
[unlike FC which defines a seperate ABTS-LS protocol for I/O
Error Recovery].

2) The technique[s] that should be used to bridge missing CmdSNs when an
initiator chooses not to "retry" a command on a connection failure or a digest

error, in order to prevent other CmdSNs ahead in the sequence from stalling,
awaiting receipt of the missing CmdSN.

Regards,
Santosh