Message-ID: <AEC4671C8179D61194DE0002B328BDD259BE0E@ATLOPS>
From: Eddy Quicksall <eddy_quicksall@ivivity.com>
To: Alex Aizman <aaizman@silverbacksystems.com>, ips@ece.cmu.edu
Subject: RE: iSCSI: connection failure in a multii-connection session
Date: Fri, 28 Feb 2003 12:42:58 -0500
MIME-Version: 1.0
Content-Type: text/plain
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Here is a swag at it without taking too much time ...

This is effectively your item (2) below:

All of the tasks on the lost connection will get terminated and internally
treated as if a CHECK CONDITION at the target. That means the host will not
get a response to each task. The host will timeout on the outstanding
commands and will try to abort them but will see the lost connection. The
host driver should then return a response to the host saying the command was
aborted. Hopefully, the host will re-issue the command and the driver can
send it over a good connection.

It is true that the terminated commands could have SCSI ordering problems.
In that case, the host should be using ACA (Ugh). The good news is that
ordered and head of queue commands are usually not used.

For item (3) below, are you talking about aborts?


Eddy

-----Original Message-----
From: Alex Aizman [mailto:aaizman@silverbacksystems.com] 
Sent: Thursday, February 27, 2003 8:48 PM
To: ips@ece.cmu.edu
Subject: iSCSI: connection failure in a multii-connection session

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:

Initiator sends Logout(1, CID) on one of the remaining good connections
to cleanup the failed connection, ID=CID.

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.

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.

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?

Alex