iSCSI: Session Consensus/Plan

[Black_David@emc.com]

Since traffic on this has died down, we may be close
to consensus.  Let me try to state what I believe
the consensus is and propose some means for making
further progress ...

There were four possible requirements for a session
abstraction:

R1) Tape parallelism and failover
R2) Stripe data: one command, multiple links
R3) Stripe data: one command, same links
R4) Recover from TCP failure without SCSI failure

Steve Byan proposed:

R5) Stripe commands and data: multiple links, ok to restrict
	each command and associated data to a single link

I had not listed that, because if Tape (R1) is factored
out then load balancing and failover across the links involved
is achievable for disk above the SCSI level via multiple
SCSI connections.  In contrast, use of multiple links to tape
must be below the SCSI level (i.e., in the transport).

The original four requirements appear to fall into three categories:

1) I have seen no objections to R1) [Tape parallelism and
	failover].  Therefore I believe rough consensus exists
	for a session abstraction that bundles multiple transport
	connections into a single iSCSI connection, but that
	support for multiple connections/session is OPTIONAL.
	It would be ok to delete failover from this consensus
	for the reason discussed in the next paragraph.
2) R2) [Stripe data: one command, multiple physical links]
	and R4) [Recover from TCP failure without SCSI failure]
	require a detailed design to evaluate whether they should
	be requirements.  In particular, R4) has been the focal
	point of the "keep it simple" objections to the session
	concept, and the complexity of achieving R2) depends on
	the details of the session design (what data and/or
	commands are allowed on which connections when).
3) Costa has characterized R3) [Stripe data: one command,
	same physical links] and generalizations involving
	multiple TCP connections over the same link as weak,
	and I've seen no disagreement.  In the absence of
	strong support for R3), I believe rough consensus
	exists to reject it as a requirement. The final
	session abstraction may be able to do this, but
	will not be REQUIRED to do so.

In summary: R1) would be the major reason to require sessions,
R2) and R4) are potential goals for the selection/design
of the session abstraction, and R3) is not a requirement.
Anyone who disagrees should comment on the list.  It would
be fine to re-raise the complexity objection to sessions
when the complete design including error handling is done,
but re-raising it at this juncture is probably not productive.

Based on the above consensus to have a session abstraction,
the next issue is to determine what that should be.  I think
we're going to need two parallel efforts on this, because in
addition to the previous possible session models ...:

- All connections are equivalent, but all traffic
	for a single SCSI command uses one connection.
- Single control connection, but data traffic can
	be striped across multiple connections.
- LUNs are assigned to specific connections.

... a new one has been proposed:

- Use SCTP instead of TCP and employ SCTP's support
	for multiple paths to the same destination.

SCTP's multi-path support appears to be primarily designed
for failover, but there are hooks that appear to make it
usable by load balancing logic that resides above SCTP.
We need further discussion of SCTP, as in the discussion to
date I have seen neither a comprehensive design for
encapsulation of either FC or SCSI in SCTP, nor have I
seen any showstopper to the use of SCTP.  Comments
are hereby solicited ...

Determination/design of the session abstraction for
iSCSI over TCP should go on in parallel with the SCTP
discussion, as that should continue to expose
particular requirements of SCSI encapsulation, such
as how transparent recovery from errors needs to
work.

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