Re: iSCSI: Session Partial Resolution

["John Hufferd/San Jose/IBM" <hufferd@us.ibm.com>]

Mark,
Just for correct communication, you might want to make your comments
consistent between the words Session and Connection.  They are not the same
thing.   What was talked about by David was Multiple Connections.  The
context was Multiple Connections per Session.  David did not make any
statements with regard to Multiple Sessions.

I would think there could be Multiple Sessions between a Host and a Storage
Controller (yet still be consistent with David's statements) as long as No
overarching iSCSI relationship existed between the commands and data in the
different sessions.  This is the case with FC today.  If there is multiple
Sessions, a Wedge Driver can be used to balance or be used to provide for
vendor specific alternate path recovery.

.
.
.
John L. Hufferd



"Mark A. Carlson" <mark.carlson@sun.com>@ece.cmu.edu on 09/20/2000 03:35:05
AM

Please respond to mark.carlson@sun.com

Sent by:  owner-ips@ece.cmu.edu


To:   Kalman Meth/Haifa/IBM@IBMIL
cc:   Black_David@emc.com, ips@ece.cmu.edu
Subject:  Re: iSCSI: Session Partial Resolution



Support for multiple sessions has always been optional.

So lets get a specification out there that shows how
to do iSCSI when you don't support multiple sessions.
The only other thing we need specify then, is some way
to say that the implementation does support multiple
connections, and then that work can proceed in another
document on another time schedule and companies that
were not going to implement multiple sessions initially
anyway can start work.

If you like, this can be the spec for the degenerate
single connection symmetric model since I think there
is consensus that a single connection cannot be asymmetric.

David is just trying to move us along and eliminate
possible rat holes that will hold up the end result.

-- mark

meth@il.ibm.com wrote:
>
> David,
>
> If we eliminate all support for multiple connections from the next
version
> of the draft and have a separate draft for multiple connections, then
we'll
> eventually end up with 2 different (incompatible) protocols. Depending on
> whether we have a single connection or multiple connections, the
initiator
> and target will have to implement one or the other or both protocols.
Some
> products that implement only one version will not be compatible with
other
> products, etc, and we will have shot ourselves in the foot. The wide
> acceptance of iSCSI will be strongly influenced by the ability to
> inter-operate with all kinds of devices and products, many of which will
> greatly benefit from one of the various multiple-connection models.
>
> I recommend to try to focus on the question of the multiple-connection
> model to see if we can at least agree that one or more of them
sufficiently
> satisfies the requirements, and then choose one of the satisfactory
models.
> Even if we can't agree on which model is the best, I think we can
> more-or-less agree on which of the models is at least good enough.
>
> - Kalman Meth
>
> Black_David@emc.com on 19/09/2000 22:22:20
>
> Please respond to Black_David@emc.com
>
> To:   John Hufferd/San Jose/IBM@IBMUS, Black_David@emc.com
> cc:   ips@ece.cmu.edu (bcc: Kalman Meth/Haifa/IBM)
> Subject:  iSCSI: Session Partial Resolution
>
> <... deleted ...>
>
> 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.
>
> <... deleted ...>
>
> --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
> ---------------------------------------------------