Re: Connection Consensus Progress

[julian_satran@il.ibm.com]

Chris,

Thanks for the clarification. Unlike proprietary wedge drivers the iSCSI
recovery mechanism is meant to be generic.  It might get help from HBAs
(like detecting a failing connection)
but it can be implemented entirely above TCP (at the iSCSI level).

Here is a comment I sent about wedge drivers:

--------------------------

I assume that FC folks where so overwhelmed by how complex the FCP ended up
being that
they did not even contemplate doing multiple connections.

And the FCP complexity is caused by stressing too much the hardware
implementation
in the first place and then placing functions with the hardware
implementation in mind
as the #1 concern.

However an older stuff - the ESCON had it all there - multiple connections
built
in a channel group.

The only thing we are trying with the connection group is bringing back
some sanity
and devising only basic recovery mechanisms. And I am proud that we did it
with so little
complexity (Kalman's proposal could simplify it further).

With so many proprietary things - if we leave them as they are - we might
end
having a multitude of incompatible implementations because of unexpected
failure
modes for which the wedge drivers will break.
------------------------

Julo

Christopher Stein - Network Storage <Christopher.Stein@east.sun.com> on
28/08/2000 18:51:16

Please respond to Christopher Stein - Network Storage
      <Christopher.Stein@east.sun.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  Re: Connection Consensus Progress





Hi,

John Hufferd interpreted my point correctly and set me straight on
"wedge" drivers (thanks, John) -- a software component in the iSCSI
driver that load balances across multiple HBA TCPs.

Of course, it may be a challenge to get anyone but a second-rate
engineer to build something as unbeautiful as a "wedge" driver,
fating it to be a single-point potentially more buggy than the
HBAs themselves. As an added bonus, the fault profile would
be software, rather than fail-stop hardware (which top firmware
engineering in the HBA could present to the iSCSI driver).

-Chris

>
>Chris,
>
>Could you elaborate?
>
>Julo
>
>Christopher Stein - Network Storage <Christopher.Stein@east.sun.com> on
>26/08/2000 23:53:13
>
>Please respond to Christopher Stein - Network Storage
>      <Christopher.Stein@east.sun.com>
>
>To:   ips@ece.cmu.edu
>cc:    (bcc: Julian Satran/Haifa/IBM)
>Subject:  Re: Connection Consensus Progress
>
>
>
>
>
>Julian,
>
>If one of the reasons for supporting multiple TCP connections is
>to allow load balancing across HBAs for fault tolerance, this
>reason will be lost as the TCP processing moves down into the HBA.
>
>My understanding was that TCP on a chip technology is desired for
>high-performance iSCSI. If this is the case, then multiple
>connections for tolerance of HBA faults is a misfired bullet.
>
>-Chris
>
>>>X-Authentication-Warning: ece.cmu.edu: majordom set sender to
>owner-ips@ece.cmu.edu using -f
>>From: julian_satran@il.ibm.com
>>X-Lotus-FromDomain: IBMIL@IBMDE
>>To: ips@ece.cmu.edu
>>Subject: Re: Connection Consensus Progress
>>Mime-Version: 1.0
>>Content-Disposition: inline
>>
>>
>>
>>David,
>>
>>I understand and share your concerns about how good we understand the
>>requirements for recovery and balancing.
>>
>>But as I stated repeatedly we can't wait for somebody else to solve our
>>problem and the
>>field requirement is there as witnessed by the products that attempt to
>>solve it in a
>>proprietary fashion (and BTW a TCP connection failure could also be
>>repaired simply by
>>TCP but TCP does not do it).
>>
>>However if they are there the both sets have to be solved at SCSI level -
>>since several links
>>if not handled properly increase the failure probability.
>>
>>However your last point about multiple HBAs is lost on me.
>>We attempted to make iSCSI work with several HBAs and went to some length
>>to keep
>>the requirements to the HBA hardware as if the HBAs act independently
>>(counters can be
>>shared). Is there something we missed?
>>
>>Julo
>>
>>David Robinson <David.Robinson@EBay.Sun.COM> on 25/08/2000 23:32:23
>>
>>Please respond to David Robinson <David.Robinson@EBay.Sun.COM>
>>
>>To:   ips@ece.cmu.edu
>>cc:    (bcc: Julian Satran/Haifa/IBM)
>>Subject:  Re: Connection Consensus Progress
>>
>>
>>
>>
>>> I agree with you up to a point.  I know of customers that always need
>>> multiple physical paths to the Storage Controller.  Regardless of how
>>fast
>>> the link is, they need a faster link, and these hosts need to be able
to
>>> spread the load across several different HBAs.  (Some are on one PCI
>bus,
>>> and some on another, etc.)  When this happens, as it does today, with
>>Fibre
>>> Channel, we are required, as are a number of other vendors, to come up
>>with
>>> a multi HBA balancer.  We call our Fibre Channel version "DPO" (Dynamic
>>> Path Optimizer), EMC has another version (I do not know what they call
>>> theirs).  This Code sits as a "Wedge" Driver above the FC Device
Drivers
>>> and balances the work across the different FC HBAs.  I think this same
>>> thing will be required in the iSCSI situation.  Note:I think, the FC
>>> versions only work with IBM or EMC's etc. Controllers.  (SUN probably
>has
>>a
>>> similar one also.)
>>
>>I understand this scenerio, it is often used as a high availability
>>feature.
>>The key question is if this should be handled above at the SCSI layer
>>as it is most often done now, or in the iSCSI transport. While I like
>>the goal to unify this into one architecture, I have serious doubts that
>>we have the understanding of the requirements and needs necessary
>>to get it right.  Thus we will ultimately end up in the same situation
>>we are in today with a SCSI layer solution.  In addition, if the promise
>>of a hardware iSCSI NIC/HBA is acheived, allowing multiple paths using
>>different NIC/HBAs will still require "wedge" software.
>>
>>     -David
>>
>>
>>
>>
>>
>
>
>
>
>

---

Christopher A. Stein     (cstein@east.sun.com)
Network Storage, Sun Microsystems, Inc.
BUR02-213 1 Network Dr.
Burlington, MA 01803-0902
781-442-2343