RE: iSCSI: Session Partial Resolution

["GUPTA,SOMESH (HP-Cupertino,ex1)" <somesh_gupta@am.exch.hp.com>]

David,

Would it be reasonable to ask for a "show of hands" on
these from the participants on this WG on the two
issues? I thought that at least regarding 1, there was
some consensus building (or at least a number of people
were in favor of) need to avoid the queue full condition
etc and to account for the increased latencies of IP
networks (without leaving it upto T10 to fix our
problems).

Somesh

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Tuesday, September 19, 2000 12:22 PM
To: hufferd@us.ibm.com; Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: iSCSI: Session Partial Resolution


> Perhaps I am wrong but it seems we are drifting and not focusing on the
> search for concurrence regarding Symmetric vs Asymmetric.  What is your
> view?

John's acquiring the prescient talent of causing the
co-chair to appear and take action ... as long as he
doesn't start calling himself a "wizard" based on these
summoning powers, I won't object :-).  In any case ...

In the past week, I have seen at most one objection
to each of the following two proposed points of consensus:

(1) An iSCSI session containing a single TCP connection
	should not be required to use the currently specified
	iSCSI command reference numbers and sliding window
	mechanism because TCP will deliver commands in order.
(2) Use of more than one TCP connection per iSCSI session
	is OPTIONAL.

Therefore I declare these to be the WG rough consensus on
these issues, and the next version of the iSCSI draft
should remove the command reference numbers and sliding
window mechanism from the iSCSI header.  Somesh Gupta's
objection to (1) and Matt Wakeley's continued objection to
(2) are noted as part of declaring these to be the WG rough
consensus.  Anyone else who objects to this declaration
of rough consensus should email me directly with the
reasons for the objection.

OTOH, I do not see consensus on the session model for
multiple connection sessions among the Asymmetric model,
the Symmetric model, and Pierre Labat's proposal.  In
order to make progress on iSCSI, I see no alternative to
separating multi-connection sessions from the main iSCSI
spec.  Significant effort and email traffic has been
invested in this topic for at least 6 weeks and the issue
is not settled -- I don't think holding up the iSCSI spec
for another 6+ weeks in hopes of settling this issue on
the list is an effective way to make progress, but I'm
prepared to listen to dissenting opinions (e.g., if
someone thinks there is rough consensus, and I've missed
it); please send such opinions directly to me rather than
using the list.  I've already had one offline comment from
an outside observer expressing amazement at the willingness
of this community to discuss multi-connection sessions
"ad nauseum".

Therefore, I would ask that the authors of the next
version of the iSCSI draft delete all specification
of multiple connection sessions from the next version
of the except for a note that they will be handled in 
a separate document.

Producing that separate document is going to require
an offline design team.  The design team can either be
chartered to write a compromise session specification
or to evaluate competing specifications and choose one.
My current inclination is to do the latter, which would
involve having the design team produce a set of requirements
and guidelines for session specifications in consultation
with the co-chairs, evaluate Internet-Drafts documenting
the specifications, and recommend an approach to the WG.
Comments on this process are solicited - either on the
list or to me directly.  Further discussion of multi-connection
sessions on the list is probably not a good use of list
bandwidth.

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