Symmetric vs Asymmetric

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

David,
One of the reasons I was holding out for Symmetric over Asymmetric, was for
the workload balancing etc. that could be done at the iSCSI layer.

I am now willing to "roll-over" but I think I owe you all my reasons for
deciding to support the Asymmetric approach:

First, in the degenerate case, they both look the same.  That is, they can
both support  a single Connection per Session.  So the simplest
implementation is still possible with the Asymmetric approach as it was
with the Symmetric approach.  This means that most current iSCSI
implementations can continue to exist, unchanged.

But the most important reason follows:

Since a session is a unique construct that identifies an Initiator and a
Target, I am assuming that does NOT mean each NICs has a unique initiator
ID but that they can, and should, share a common Initiator ID.   The Target
ID, on the other hand,  is either unique per Storage Controller, or not,
and this will depend on the type of Storage Controller.  This means that
the Host iSCSI device driver will be able to present, to the layers above
it, either a single port per storage controller, or multiple ports,
depending on how the Storage Controller answers Logins on each of its IP
connections.

That means iSCSI will not be able to determine when it knows enough to
perform alternate path retry, and for the same reason will not be able to
know when or how to perform command work load balancing across the
different sessions.  This is because either all connections to a storage
controller have either the same iSCSI session ID (SSID), or they are
different -- but iSCSI will not, by itself, know which sessions can be
substituted for others (for balancing or retry).

The only place where the symmetric approach can do workload balancing and
alternate path retry is where the storage controller makes it look like a
single target ID even though it might have multiple IP addresses.  Though
this might work in some IBM storage controllers (like Shark) it will not
work for all IBM storage controllers (like those of Mylex).  This same or
similar argument probably will apply to EMC's and other vendors various
storage controllers.  Therefore, having iSCSI do any type of command
balancing or command automatic alternate path retry is problematical
without outside influences (probably from upper layers) and this will tend
to make the iSCSI layer very thick and complicated.  It will also mix the
layering concepts (in general not a good idea).  Therefore, I now believe
that the Symmetrical approach can not be a reasonable general/generic
approach to Command work load balance or alternate path retry, and that
function is best left to the Wedge Drivers.

The Asymmetric approach can not perform command balancing or command
automatic path retry either, but it does not try.  It only tries to balance
the data across multiple connections (and that seems much more reasonable).

With the Asymmetric approach, data for any specific command only flows on
one connection.  So you can look at the data from various commands as
independent flows on the different connections (NICs) so there should not
be blocking issues, or parallel flow issues, and RDMA type direct to memory
functions can occur.

With multiple storage controllers, there may be many sessions and many data
connections spread across all the various NICs in a Host.

The net of all this is that the Asymmetric approach:
   Probably  has good enough spread of commands and data across multiple
   NICs, even without Wedge Drivers.
   Permits the upper layer Wedge Drivers to be left mostly unchanged.
   Permits the simple case with a single connection per session, even with
   multiple NICs.
   Permits the most simple case of a single connection per session with
   only a single NIC.

 Since I have seen no one else that made arguments for the Symmetric
implementation, you maybe able to call the agreement on the Asymmetric
approach a consensus.
.
.
.
John L. Hufferd