RE: Connection Consensus Progress

["Douglas Otis" <dotis@sanlight.net>]

David,

As I am not convinced you are asking the correct questions, let me pose some
of mine.

Question E(sctp)
Should use of TCP be changed to SCTP allowing for-
. Headers contained within one frame.
. Objects aligned at 32-bit boundaries.
. Out of sequence frame processing.
. Standard authentication.
. Independent streams under common control.
. Session restart (no multi-session binding required for reliability).
. Improved error detection.
. Prevention of blind spoofing and denial of service attacks.
. Standard Heartbeat and multi-homing. (optional improvement for
reliability)

Add to this list or reorder by importance.  Getting TCP done is half the
battle with an object stream like SCSI. SCTP allows simple state-machines to
handle this entire nightmare of obtaining performance. (The deciding factor
in the end.)  Perhaps they should rename SCTP to TOP for Transport Object
Protocol or perhaps GTSSB Greatest Thing Since Sliced Bread.

Question A(sctp) revised
Should LUN resolve to stream?

Question B(sctp)
SCTP streams, session restarts, and switches obsolete Question B.

Question C(sctp)
Should systems connecting to Fibre-Channel retain FCP structures?

Question D(sctp)
If using FCP structures, should FC domain resolve to a stream?

Doug

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Black_David@emc.com
> Sent: Friday, August 18, 2000 1:50 PM
> To: ips@ece.cmu.edu
> Subject: Connection Consensus Progress
>
>
> > 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
> ---------------------------------------------------
>