RE: iSCSI Autosense Consensus, Connection next steps

[Joshua Tseng <jtseng@NishanSystems.com>]

David,

If I may give my input on the TCP connection model discussion, I'd like
to advocate the asymmetric model for the following reasons.  Using
multiple TCP connections, each TCP connection will likely have
different performance characteristics.  If this is so, then some commands
may reach the target out of order from other commands sent down different
TCP connections.  Commands sent down the faster connection will then need
to be buffered until commands sent down slower connections arrive.  This
will lead to the following problems that I can think of:

1)  There will be increased memory requirements for the iSCSI target,
which must buffer commands and related data and reorder them before passing
them on to the SCSI controller.

2)  If the initiator cannot sense the performance characteristics of
each TCP connection, then interactions between initiator and target will
be dependent on the slowest TCP connection.  For example, if there are
five TCP connections and one of them is extraordinarily slow, and the 
initiator merely round-robins the commands down each of the five
connections,
all interactions between initiator and target will be only as fast as the
slowest connection.

In addition, it has been stated that detecting and recovering from a failed
asymmetric control connection is more complicated and difficult than
detecting and recovering from a failed symmetric data/command TCP
connection.
I do not understand why this is so.  In both cases, iSCSI initiator will
need
to abort the lost command AND those following the lost command, and resend
all
commands in a new or different TCP connection.  In the symmetric case, iSCSI
commands received by a target following a lost command will not be
acknowledged,
since ExpStatRN is a cummulative windowing mechanism.

Josh Tseng

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Sunday, September 03, 2000 8:20 AM
To: julian_satran@il.ibm.com; ips@ece.cmu.edu
Cc: Black_David@emc.com
Subject: iSCSI Autosense Consensus, Connection next steps


> It looks like we have consensus - but the chairmen have the call.

Indeed we do, and I apologize for the delay, due to an inability to
get connected.

First, on Autosense, I believe that rough consensus exists for
iSCSI to require Autosense.  I have seen only one objection;
If anyone other than Doug Otis disagrees with this, please
say so on the list.

Second, on connections, I haven't seen enough discussion to call
consensus, but I am going to try to narrow the option space and
structure the discussion.  Four models for sessions have been
proposed:

(1) Symmetric - all connections usable for command and data.
(2) Asymmetric - single command connection, others are data.
(3) Split - assign LUN sets to specific connections or pools of
	connections.
(4) SCTP - use SCTP's support for multiple connections.

I have only seen one message suggesting/supporting (3) Split, so
I believe rough consensus exists to not pursue that model
any further.  If anyone other than Paul von Stamwitz disagrees,
and believes that the Split model should be pursued, please
say so on the list with technical rationale.

I haven't seen enough discussion on use of SCTP instead of
TCP to call consensus.  I am concerned that this list is not
going to produce a consensus on the issue phrased in that
fashion (i.e., pick exactly one).  The one point on which there
does seem to be consensus is that SCTP is a considerably
younger protocol that TCP, and hence the likely timelines
to availability of hardware acceleration seem to favor TCP.
OTOH, this sort of future prediction can easily miss the mark.

I can see two possible ways to make progress in this area:
- An off-line design team to do an intensive evaluation of SCTP
	vs. TCP for iSCSI.
- Recognize the merits of SCTP as well as TCP, plan for both
	with the anticipation that TCP will be used first.
The latter makes more sense to me, because it appears to
be more amenable to consensus, avoids the investment
of effort in the design team, and avoids having the prospect
of abandoning TCP hanging over the heads of those engaged
in TCP-specific work.  The practical implication of proceeding
in this fashion is that SCTP-friendliness becomes an additional
criteria to use in evaluating iSCSI design proposals.  Proceeding
in this fashion is only a proposal at this juncture -- please
comment on whether this is the right way to proceed (to me
or on the list).

The specification of sessions for iSCSI over TCP needs to
proceed, so under the assumption that either the "plan for
both" path will be pursued, or that we can't wait for the
design team's conclusions, and hence need to work on TCP
in case it is selected, I want to summarize the tradeoffs
between the Symmetric and Asymmetric session models,
in the aim of simulating more discussions so that we can
get to consensus.

[X] The Symmetric model imposes additional work on implementations
	that do not use multiple connections because they will
	have to implement the command numbering.  The
	Asymmetric model does not do this.
[Y] The Asymmetric model makes dealing with a failed control
	connection more complicated than the symmetric model
	because agreement between the two sides is required
	to establish a new control connection (or use an existing
	data connection for control).

I have seen the discussion of [X] favoring Asymmetric for systems
that will not support multiple TCP connections per iSCSI session.
I also note (as an example of applying the SCTP-friendliness
from above) that [X] favoring Asymmetric also applies to SCTP, as
there seems to be no point in using multiple SCTP sessions in a
single iSCSI session.

We need to give the folks working on revising the iSCSI draft some
direction on this issue in fairly short order, so comments are hereby
solicited ...

Thanks,
--David

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