Re: Connection Consensus Progress

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

David,
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.)

If possible I would like to avoid adding a vendor specific wedge driver, or
better yet avoid any kind of an additional wedge driver with the iSCSI, by
building the same capabilities into the Transport layer.

Having said that, I would like to see the multiple Connection per Session
(as it applies to multiple Ethernet Ports) kept in the spec. with the
understanding that one connection per session is a proper subset.  If we
did that, the simpler and early implementations can get to market quickly,
and we can use things like DPO for a while.  I would just like vendors that
could write the multiple connection iSCSI Device Drivers  to  actually do
it, and then load balance between the HBAs without depending on external
Wedge Device Drivers.

.
.
.
John L. Hufferd


David Robinson <David.Robinson@EBay.Sun.COM>@ece.cmu.edu on 08/25/2000
11:52:37 AM

Please respond to David Robinson <David.Robinson@EBay.Sun.COM>

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


To:   ips@ece.cmu.edu
cc:
Subject:  Re: Connection Consensus Progress



Just for the record, I will restate that I prefer to have a single
TCP connection per initiator/target session. The complexity of error
handling greatly outweighs the perceived performance implications.
Also any performance problems are not fundemental limitations of TCP
but issues in existing implementations, complicating a protocol to
cover bad/lazy implementations is a bad idea.

iSCSI should not try to end-run congestion control, creating and managing
multiple connections may cause unexpected interactions with congestion
control algorithms and other QOS mechanisms.  I don't know this to
be true but we must be certain we are not causing problems before
we go down this path.

     -David