iSCSI: Partial Session Consensus

[Black_David@emc.com]

In reading the mailing list traffic on Asymmetric
vs. Symmetric models for multiple TCP connections
in an iSCSI session, I don't believe that there is
consensus on the issue phrased in that fashion.

I believe that there is consensus on a couple of
underlying issues:

(1) An iSCSI session containing a single TCP connection
	should not be required to use the currently specified
	iSCSI command reference numbers and sliding window
	mechanism because TCP will deliver commands in order.
(2) Use of more than one TCP connection per iSCSI session
	is OPTIONAL.

The consensus on (1) is rough; if anyone disagrees with
this for a reason other than wanting to use the Symmetric
model when an iSCSI session contains multiple TCP connections,
please say so on the list.  My reading of consensus is
based on the fact that much of the recent discussion of the
Asymmetric model has been motivated by single connection
sessions, whereas essentially all of the recent discussion
of the Symmetric model seems to have been focussed on
multiple connection sessions.

The consensus on (2) is sufficiently long standing to be a
closed issue.  The resolution to the "deadlock" scenarios posted
by Costa is that the target must not stop reading from the TCP
connection - SCSI provides means for a target to throw away
things it can't deal with (e.g., TASK SET FULL), and with
regard to the ordered command issues, I believe Steve Byan
is correct when he says:

	I think this is a T10 bug, and iSCSI should defer to T10 to fix it.

In addition to Steve noting that disks tend not to use ordered
commands, I would note that a single tape device/drive tends
not to have multiple simultaneous initiators sending commands
to it, both of which limit the practical impact of this potential
problem.

I don't see consensus on the model for iSCSI sessions that
contain multiple TCP connections.  The consensus on (1)
above for single TCP connection sessions does not take the
Symmetric model out of consideration for multiple TCP connection
sessions.  If multiple sessions are negotiated on connection
establishment, command reference numbers could be added to
subsequent headers as a result of that successful negotiation.
In order to make progress, this additional complexity should not
be used as an argument against the consensus in (1) for single
connection sessions.

I hope the consensus on (1), or something close to it holds,
as if it does not, we may have to form an offline design team or
teams to work on this set of session issues, and that could take
some time ... meanwhile, discussion of Asymmetric vs.
Symmetric for multiple connection sessions should continue.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------