RE: iSCSI: symmetric/asymmetric & "Wedge" drivers

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

Julian,
As I understand the Asymmetric proposal,  it is an extension to the Single
Connection per Session (SC/S).  The extension to SC/S   permits data to be
sent on other TCP/IP connections (which may or may not be on other
NICs/HBAs).

This means, I think, that if the Asymmetric proposal is accepted, that the
whole discussion we had over whether or not we need the Wedge Drivers to
perform "Alternate Path" retry, is moot.  Wedge Drivers, I believe,  will
be needed to do that function if Asymmetric is chosen, since we have no
construct, other then Session, to identify "Alternate Retry Paths".  And in
this case, the Session only identifies other Data Channels, not other
Alternate Command Paths, leaving no way to know what the Alternate Retry
Path might be.

Is my analyses correct?



.
.
.
John L. Hufferd



julian_satran@il.ibm.com@ece.cmu.edu on 08/29/2000 07:53:58 AM

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


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: "Wedge" drivers





David,

I understand 3 and I somehow expected it. If I would have to reimplement
this
under iSCSI I would choose a plug-in in iSCSI to do it (a policy module)
and
iSCSI would clearly support such a construct (and make it also
future-proof).

I have some trouble with 1 and 2.  In whatever design you choose at the
array
level you have to have some sharing as some commands are targeted to a LU
and all it's queues (i.e. separation per initiator is never complete if you
take SAM seriously).
However some design might choose to share only for those commands - and
talking to you
with you chair hat off - I don't think that you are with one of those (:-

I am no sure I understand 4 either - if the array does no "sense" the fail
over.

Now talking to you with your hat on - we are ready to get to the drafting -
but I feel
that we are still left with the symmetric/asymmetric dilemma and I would
appreciate
input:

The asymmetric solution is simpler for those using a single connection.

Is there any serious drawback?

Dear Colleagues - Please give us feedback.

We can choose only one solution?  Which is the right one?

Julo

Black_David@emc.com on 29/08/2000 16:26:49

Please respond to Black_David@emc.com

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: "Wedge" drivers




> While many of you keep telling me that wedge drivers won't go away nobody
> gave one good example to support that assertion.

With my co-chair hat off, here are four, two from the mail exchange:
(1) Sharing SCSI state across array interface processors involves some
     work.  Use of multiple SCSI connections and wedge drivers
     for fault tolerance and load balancing will persist in systems that
     choose not to follow that implementation path.
(2) If iSCSI is implemented in hardware, so that a system has multiple
iSCSI
     HBAs rather than multiple NICs with a common iSCSI software
     stack, multiple SCSI connections and wedge drivers are again
     the path of least resistance to fault tolerance and load balancing.
And two new ones:
(3) Naive greedy load balancing is not optimal.  Significant improvements
     are possible based on an understanding of how the storage behaves.
     PowerPath contains Symmetrix-specific logic that does this,
     and I don't think that's appropriate for standardization.
(4) Some arrays need additional support for fail-over.  Clariion uses
     an active fail-over architecture in which the array must be
     instructed to fail-over, and the fail-over occurs across separate
     SCSI connections.  I don't think that the Clariion-specific
     logic that does this is appropriate for standardization.
As I wrote earlier, I have no problem with specifying a session abstraction
for iSCSI, but it won't eliminate wedge drivers.

With my co-chair hat on, the current consensus is to specify a session
abstraction and review the result.

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