Re: iSCSI Autosense Consensus, Connection next steps

["Randall R. Stewart" <randall@stewart.chicago.il.us>]

David:

Nice summary... please see my thoughts to the
transport issues below...

Black_David@emc.com wrote:
> 
> > 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.
> 

I don't really think that it matters in the SCTP sense if you are
using X and Y... In fact in Y it is easier to establish a new
association/connection (if you were using seperate SCTP associations
which I would strongly recommend AGAINST). This is because SCTP supports
both a TCPish flavored model and a UDPish model.. In the UDPish model
you just send to a peer (that you do NOT have a association with) and
the SCTP stack will automatically create the association. There is
not need to keep connection state etc.

Now on the multiple connections issue. I really strongly advise AGAINST
this. I could understand 1 control connection and 1 data connection, but
if you do N data connection you are breaking the congestion control 
algorithms. Earlier a pointer to some comments from Sally Floyd were
posted.. please go have a look at these (I did) and I totally agree
with Sally. Having N connections violates the CC of the network and
is a very very BAD idea. I do understand why you would want to have
your control (with TCP) in a seperate connection. As long as this
is a low bandwidth type of connection it is probably ok. 

You would not need to do this with SCTP though, since the multiple
streams allow you to have 1 stream dedicated to control and N streams
dedicated to data. And (optionally) you can even have a no or one
retransmit
stream for data (as well as full reliablility).  

I will post more comments to this thread, I do see it is long, I have
been updating the reference implementation of SCTP and have been
disconnected from email a bit...:0



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

-- 
Randall R. Stewart
randall@stewart.chicago.il.us or rrs@cisco.com
815-342-5222 (cell) 815-477-2127 (work)