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

[Amir Grimberg <amirg@mercury.co.il>]

-----Original Message-----
From: Amir Grimberg [mailto:amirgr@barak-online.net] 
Sent: ג 04 מרץ 2003 7:55
To: amirg@mercury.co.il
Subject: Fw: iSCSI: connection failure in a multii-connection session


----- Original Message -----
From: <Black_David@emc.com>
To: <aaizman@silverbacksystems.com>; <ips@ece.cmu.edu>
Sent: Friday, February 28, 2003 7:01 PM
Subject: RE: iSCSI: connection failure in a multii-connection session


> 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
> ----------------------------------------------------
>