Connection Consensus Progress

[Black_David@emc.com]

> I understand that some folks want to have many TCP connections to a
storage
> entity, including at least one TCP/IP connection per LUNs.  I think it has
> been agreed by Julian that iSCSI will support that, with some extensions
> which he suggested.  Even though most folks will not implement their
> Storage Controllers in that manor, I think that issue is perhaps settled.
> Julian could perhaps restate the change that would make the TCP per LUN
> folks (if more then one) happy. This may permit us to really move off of
> point "A" (specified by David Black as "Should iSCSI require a TCP
> connection per LUN?").  If that is so, then I also submit that we have not
> been focusing enough time on point "B" ("Should iSCSI have a session
> abstraction that binds multiple TCP connections into one iSCSI
connection?").

If I weren't on vacation and dealing with email sporadically,
I'd have sent email along the lines of what John Hufferd
wrote above.  I think that the discussion of (A) has lead
to the rough consensus that iSCSI will not REQUIRE a TCP
connection per LUN.  It is still possible to build systems
that use a connection per LUN (e.g., a collection of targets,
each of which only implements LUN 0, although initiators
will be REQUIRED to support multiple LUNs/target).  The
consensus is a bit rough, but I think it is consensus.  If
anyone disagrees (i.e., thinks that things are too rough
to be called consensus), please send me email directly.

The session discussion (B) has been widening the scope
of possibilities.  We need to start narrowing it.  In
looking over the emails on this topic, there are a bunch
of intertwined issues.  The original issue (B) was:

(B) Should iSCSI have a session abstraction that
	binds multiple TCP connections into one
	iSCSI connection?

For a "yes" answer to (B) we need a clear grasp of the
requirements that motivate multiple connections (i.e.,
what problems does they address).  So far, I think
I've seen:
R1) Parallel transfers to/from and failover support for
	tape devices.  In contrast to disks, multiple SCSI
	connections to the same tape do not work (e.g.,
	blocks can be written in the wrong order).
R2) Obtaining parallelism for a single SCSI command
	across multiple transport connections using
	different physical links.
R3) Obtaining parallelism for a single SCSI command
	across multiple transport connections using the
	same physical links.
R4) Optimize failure handling, so that a single TCP
	connection loss doesn't immediately translate
	into a SCSI error visible to higher level
	(time-consuming) recovery logic.
R1) and R2) are beyond the capabilities of existing SCSI-
based systems (note that a parallel bus is a single link). 
R3) and R4) are related to the use of TCP as a transport.

R3) needs more explanation, as TCP is known to be able
to saturate Gigabit Ethernet, given enough data to
transfer.  Is the argument for R3) that for the
transfer sizes likely to be seen in iSCSI, TCP
spends enough of its time in slow start and the
like that multiple TCP connections gain performance?

I should also note that the error handling procedures
for multiple connections will need to be specified
in complete detail -- I expect to see state machine
descriptions in the final version of the spec if
multiple connections are supported.

Beyond this are the issues of what sort of multiple
connection model(s) to adopt if we decide to go that
route.  I've seen at least three models proposed:
- 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.
The third model is to some extent orthogonal to the
first two, and leads to another approach to building
systems with a single LUN/connection.

Can I ask people to focus on the requirements issues
for (B)?  For those in favor of multiple connections,
please indicate which of the requirements (R1-R4)
are important, or what additional requirements I've
left out.  Those against should check that none of
R1-R4 are important enough to be requirements.

I'm looking not only for Yes/No consensus on (B),
but also the corresponding discussion of R1-R4, which
I would expect to see reflected in a future version of
the iSCSI requirements draft.  Consensus of this sort
is hard to take on the mailing list, so I'd like to
see more discussion focussed on the requirements
before I figure out how to go about establishing
consensus.

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