Re: Symmetric vs Asymmetric

[julian_satran@il.ibm.com]

I agree. It has the added advantage that the header structure for data can
be
streamlined and still keep with our constant header length - although a
different constant
for data. We are close to the draft-00 structure with the recovery from
draft-01.

Julo

"Matt Wakeley" <matt_wakeley@agilent.com> on 08/09/2000 02:56:01

Please respond to Matt Wakeley <matt_wakeley@agilent.com>

To:   John Hufferd/San Jose/IBM@IBMUS, ips <ips@ece.cmu.edu>
cc:    (bcc: Julian Satran/Haifa/IBM)
Subject:  Re: Symmetric vs Asymmetric




John Hufferd/San Jose/IBM wrote:

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

The biggest issue with the "asymmetric" model is that it is NOT
"asymmetric"
when there is only 1 TCP connection.  When there is only one TCP
connection, it
is the "symmetric" model - both commands and data on the same TCP
connection.
Then, when there is more than one TCP connection, the behavior is
different.
It's always easier to implement something that operates that same way all
the
time, than two different behaviors.

I propose that the asymmetric model mandate at least two TCP connections
(implies that at least one physical connection will have at least two TCP
connections running on it) - one for commands, the other for data.  This
has
other advantages, like commands not being flow controlled by large
transfers of
data.

-Matt Wakeley
Agilent Technologies

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