RE: iSCSI: Flow Control

["Douglas Otis" <dotis@sanlight.net>]

Somesh,
<snip>
>
> I agree. The only difference of opinion I have is whether the
> credit/window should be on a per connection basis or a session
> basis.

The credit should be based on the equivalent FC frame which loosely
translates to commands, but unsolicited data should also be assessed in the
same manner.  Credit should not cover exclusively commands.

If you combine connections using a technique Cisco describes as EtherChannel
which is an encapsulation scheme with a prefix added, then the need for
treating multiple connections differently from a single connection vanish.
As this multiple path would improve strength of the connection, it could be
used for either redundancy or improved bandwidth.  Support equipment will
also provide load balancing and failure detection using this method.  I
would hope that existing solutions, being well supported, would be
preferable over a unique solution. Selecting this method of combining
adapters could also remove much of the complexity in attempting to support
multiple adapters and allow focus to remain at a level of complexity of a
single connection.

The next level of failure recovery comes in with respect to an iSCSI server
failure.  The LUNs mapped into shared targets behind the iSCSI server must
be exposed for redundancy or the iSCSi server itself becomes a point of
failure.  The mapping of LUNs to targets should be encoded within the iSCSI
LUN address.  There is enough space within the iSCSI LUN address to allow
for this transparent means of ensuring uniform mapping.  A portion of the
LUN space could be mapped to a 3 byte target address, 3 byte link address,
and 2 bytes of LUN could be assigned as a standard layout to access the
underlying structure.

To ensure failure and a uniform mapping for recovery, an external
authentication and permission (target address list or in iSCSI speak, LUN
list) server should provide information on this mapping.  As the iSCSI
server will not actually contain the storage, it should be viewed as an
indirect means of accessing the SAN.  As such, alternate means of access
becomes vital to prevent single point failures.  Adopting a standard means
of encoding addresses would help in ensuring compatibly.  Wedge drivers
would be a non-standard alternative that should be avoided.

Doug