RE: iSCSI: connection failure in a multii-connection session

[Black_David@emc.com]

Alex,

> Let's say, Error Recovery Level = 0 and one connection in a
> multi-connection session has failed. The first question is, could
> Initiator retain the functioning session with fewer connections (and the
> ERL being zero)? Assuming the answer is 'yes', here's some of the
> follow-up questions:

Yes, this is possible.

> Initiator sends Logout(1, CID) on one of the remaining good connections
> to cleanup the failed connection, ID=CID.

At this point, all active tasks allegiant to the logged out connection have
been terminated (aborted), and all other commands (received or in flight)
allegiant to that connection have been discarded, possibly (but not
necessarily) leaving holes in the CmdSN sequence.

> Initiator then either:
> 
> 1) Sends Task Abort for every unacknowledged command. This process will
> eventually synchronize *this* session sequence numbers. The problem is,
> once all Aborts are executed, the Target will proceed executing
> outstanding CmdSNs received on good connection(s), which may cause
> re-ordering on the SCSI level.

First of all, aborting of the active tasks allegiant to the old connection
by the Logout is unavoidable.  If the result is that there are no holes in
the CmdSN space after that happens, SCSI execution will continue.

If SCSI level ordering is an issue, either:
- Use an Error Recovery Level other than 0.  This topic looks like an
	attempt to get Task Reassign at level 0, and that doesn't work.
- Use some other SCSI mechanism like ACA to deal with ordering.

> 2) Alternatively, the Initiator re-issues all outstanding commands on
> the good connection(s), without changing their ITTs and CmdSNs. Target
> receives these commands (some of which may have been already executed),
> and continues normal processing in the order of CmdSNs. The question is
> whether Initiator is permitted to retry  commands using the same ITT and
> CmdSN pair on another connection after successful Logout but without
> explicit re-assignment. Section 6.2.1 in the spec seems to allow that.

That works only for the commands that were discarded or never received.
The commands terminated (aborted) by the Logout cannot be retried,
and the Target will ignore such retries.

> 3) Finally, is it a hard requirement that Initiator uses the same ITT
> that was used to send the original command? What's the logic behind this
> requirement?

Response matching.  There are retry cases in which it's possible that
the Target received and executed the command.  If the ITT changes
between the initial send and the retry, the Response could come back
with either ITT, leading to further confusion at the Initiator.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------