iSCSI sessions: Step 2

[Black_David@emc.com]

With my WG co-chair hat on, it's time to call
consensus on some of this ...

Late last week, I sent the "Let's try again" message
on iSCSI sessions, and since then I've only seen
one thread of comments to it from a combination of
Matt Wakeley and Doug Otis.  The important content
of that thread is Matt renewing his position that
more than one connection ought to be REQUIRED.  Lest
this seem like annoyance, Matt deserves credit for
being patient with the WG's indirect progress towards
consensus that made it necessary for him to renew his
objection on multiple occasions.  As I read Matt's
email, it looks like a good flow control solution
for the single TCP connection iSCSI session case
might satisfy him, but the flow control discussion
is still ongoing.

In any case, I am stating the following two items
as WG rough consensus, over Matt's renewed objection
in the first case:

[1] Multiple TCP connections per iSCSI session
	remain OPTIONAL.
[2] Multiple TCP connections per iSCSI session
	will be specified as part of the base
	iSCSI protocol.

Given that it's two months after the Pittsburgh meeting
I hope the rough consensus will hold on these items;
anyone other than Matt should object to me directly,
if necessary, I'll (reluctantly) reopen these issues
one more time (yes, this is a hint).

Moving on to the topic of models for multiple connection
sessions, let me start by trying to winnow the approaches
to Asymmetric sessions before taking up Asymmetric vs.
Symmetric again.  Four approaches to Asymmetric sessions
have been discussed.  I have not seen anyone other than
Pierre Labat support his Balanced model in which a single
stream of control moves from TCP connection to TCP connection
within a session. Therefore I believe it is the WG
rough consensus that:

[3] The Balanced Asymmetric model in which a single
	control stream moves from TCP connection to TCP
	connection in an iSCSI session will not be pursued.

Similarly, I saw no objections to the note at the end of
Julian's email, indicating that the Collapsed Asymmetric
model in which data is allowed on the command connection
even when there are multiple TCP connections in an iSCSI
session is technically inferior to both the Pure Asymmetric
and Symmetric models. Therefore I believe it is the WG
rough consensus that:

[4] The Collapsed Asymmetric model in which data is allowed
	on the command connection in multiple connection
	iSCSI sessions will not be pursued.

The Pure Asymmetric model was originally described as
requiring two TCP connections per session.  Kalman Meth
proposed a modification to it that allowed it to use a
single connection for both command and data.  Between
Kalman being the originator of the Pure Asymmetric model,
lack of objection to his proposal, and rough consensus [2]
above, I believe it to be the WG rough consensus that:

[5] The Pure Asymmetric model will only be considered
	in the modified form that allows an iSCSI session
	to contain a single TCP connection on which both
	command and data flow.

If all five of the above consensuses (consensii?) hold,
that would be serious progress.  Objections to these
should be sent to the list, except that I would ask
Pierre Labat not to object to [3] in the absence of
other objections to it.

Now comes the hard part - Symmetric vs. modified
Pure Symmetric (modified by [5] above).  There are
over 1000 email messages in my mailbox for the ips
mailing list for the past two months, and I freely
admit to not having reviewed them in detail.  I suggested
in the "Let's try again" email that more weight should
be given to those working on implementations, especially
hardware, and have not seen any objections to that
suggestion.  My impression is that the opinion of such
people has been in favor of the Symmetric model -
Matt Wakeley (Agilent), and Somesh Gupta (HP) come
to mind as examples.  I'm not confident that this is
the WG consensus, but it appears to me that the
WG is headed in that direction.  Please comment on
this - the absence of comments/objections will be
taken as a sign of agreement.

There has been no comment on the error recovery issue
since my email.  Given this and the prior statements that
TCP solves many of the tape error scenarios that are motivating
FCP error recovery, I think the authors of the next version
of the iSCSI draft are entitled to use their best technical
judgement in determining how much error recovery to specify
across multiple TCP connections in an iSCSI session, and
the WG will review it when the next version of the draft
appears.

We might be getting close to the end of the session issues.
Carefully considered comments are encouraged, but I'd ask
everyone to consider their comments carefully before sending
them, given our past experiences with this set of issues.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------