|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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 ---------------------------------------------------
Home Last updated: Tue Sep 04 01:07:35 2001 6315 messages in chronological order |