Re: iSCSI: multiple sessions b/n a pair of WWUIs.

["John Hufferd" <hufferd@us.ibm.com>]

Santosh,
Notes in text below between [Huff] and [/Huff].
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Internet address: hufferd@us.ibm.com


Santosh Rao <santoshr@cup.hp.com>@ece.cmu.edu on 05/09/2001 10:41:34 AM

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


To:   John Hufferd/San Jose/IBM@IBMUS
cc:   Black_David@emc.com, ips@ece.cmu.edu
Subject:  Re: iSCSI: multiple sessions b/n a pair of WWUIs.



John Hufferd wrote:
>
> Santosh,
> I think I am beginning to see the problem.  A given iSCSI Initiator Port
> can NOT have a second session with the same iSCSI Initiator Port and be

John,
                                             ^^^^^^^^^^^^^^^^^^^^^
Is the above "same iSCSI target port" (?).

[Huff]  correct, it was a Type-O, or Brain-check.[/Huff]


> consistent with SCSIness.  The second session could be started with
another
> ISID, (to the same iSCSI Target Port) but if the session was established
it
> would not have any of its commands and data handled via any techniques
> defined by SCSI or iSCSI.  In fact its use would require a wedge driver.

Perhaps, some of my confusion arises from a lack of understanding of
your definition of iSCSI Initiator Port and iSCSI Target Port. Some
clarification on your definition of these would help make things more
clear.

[Huff] In our Naming and Discovery Document the thing I am calling iSCSI
Initiator Port was shown as the SCSI Initiator Port.  It is the thing that
creates the sessions that talk to the Target Devices,  the Target Device
must logically receive the connection and assign it to what I was calling
an iSCSI Target Port, which in the  N&D document was shown as the SCSI
Port.

It is the (i)SCSI Initiator Port that creates Sessions and in our iSCSI
model it does this through the LOGIN command sending the iSCSI Initiator
Node Name and an approprate ISID.  The Target side's SCSI port, in our
iSCSI model exchanges its iSCSI Target Node Name and an approprate TSID.
(And Jim has been talking about how the (i)SCSI Target Port  should keep
persistent reservation information, including the ISID & TSIDs,  and use
that information to re-establish the Session and assign to the Session the
approprate Reservations that might be out standing for the approprate
(i)SCSI Initiator Port -- This port is identified by the iSCSI Initiator
Node Name and the ISID, under which the Reservation was taken.)[/Huff]


> This is the exact confusion I was trying to avoid.  Technically if you
were
> actually able to start another Session to the same Target Port, it would
> be, by definition another iSCSI Initiator Port.   The two different Ports
> would need to be coordinated by what we have been calling a Wedge Driver.


I'm not sure why you believe a wedge driver would be required to handle
such a configuration.(?) Per my understanding [which may be missing some
aspect], the host can operate in such a configuration in the absence of
a wedge driver.

Also, the host could create such multiple sessions to the same target
port in order to separate sub-sets of LUNs into different sessions and
apply different session properties to each such LUN subset.

[Huff] As for Wedge Drivers, this is a NON SCSI process that is either
Dynamic and therefore in the path to the Port, or is Static and performs
setup before the I/O is done (such as isolation of one set of LUNs from
others even though they are on the same Target).   But some one has to do
something to prevent the LUN I/O from being spread across different
sessions, such that order can not be assured.  The best performing Wedge
Drivers are those that  can send the I/O down any Session, but will insure
that it will not send any LUN I/O down another Session as long as the LUN
has I/O out standing.  However, if no I./O is outstanding to the LUN it can
balance the I/O across the different session.  So in my terms, your wedge
driver either separate the LUN I/O ahead of time statically, or it does it
dynamically (or both).  The point to remember is:  if Multiple Connections
per Sessions (SC/S) can be used, there is no Wedge Driver requirement and
the code is already in place to balance I/O across connections.   Since
SC/S is documented by the protocol, we should probably give preference in
the document to those design approaches which use the protocol to its best
advantage.   [/Huff]



>
> Today, the way we use multiple Fibre Channel Initiator Ports connected to
> the same Fibre Channel Target Ports is by use of Wedge Drivers.

With FC, connecting multiple initiator ports from the *same* host to a
single target port makes little or no sense. The host would see the same
LUNs twice through different initiator ports.

[Huff] In fact this is a frequent type of connection used by large servers,
and this is where the Wedge drivers come into action [/Huff]

A more typical configuration is to connect multiple FC initiator ports
from *different* hosts to the same target port as a high availability
configuration. Yes, in such a case, some type of cluster application
would be managing the switch-over from one initiator port to another.
(Is this the case being referred to ?).

[Huff] This is not what I was talking about, this is the typical type of
connections with Shared File Systems. and that does not need a Wedge
Driver, since the Shared File System (or Database) protects its self in
such a cluster environment.  Also no application can assume any
inter-arrival  of I/O with respect to the other system unless it does its
own coordination.  This is NOT a Wedge Driver. [/Huff]


> I think
> what you are suggesting causes the need for a Wedge Drivers to integrate
> the iSCSI Initiator Ports.


(I guess we wandered off into a different line of discussion which is
"whether multiple sessions between an initiator port and target port are
legal and required" ? :)

My answer to that would be, yes, they are legal and required. They also
do not require the use of a wedge driver. The host may configure
multiple sessions from one iSCSI initiator NIC to a given iSCSI
TargetAddress so as to access LUN subsets from different sessions, and
apply different session properties to different LUN sub-sets.

[Huff] The point is their sematicts are NOT defined by SCSI, you need what
I was calling a Wedge Driver either dynamic or Staticly, and I think you
are saying the same thing.  Yes, it can be done, but the deffinition of
what happens is NOT Standarized. [/Huff]

Such multiple sessions that are originated on the same initiator NIC
need to use different ISIDs [for all of the sessions for that given
target node] and thereby, are considered multiple iSCSI Initiator Ports,
based on the current name-disc draft's defn.

[Huff] Correct, we are back on the same page now. [/Huff]


 Not sure that we want to cause this type of
> thinking, by accident.  One of the reasons for Multiple Connections per
> Session was to remove the "Hard" need for Wedge Drivers.

IMHO, "multiple connections per session" complements wedge drivers in
their functionality but may not comletely replace them. A lot of wedge
drivers have code specific to the SCSI properties of the target and
moving all of this functionality into the iSCSI layer would imply adding
device specific code into this layer. Not the cleanest of layering
schemes.

[Huff] Correct again, there are some dynamic wedge drivers that not only
balance workload but also spring into action to help with fail over
situations.  Also the wedge drivers sometimes are needed to ensure that for
the best use of the target Raid Array Caches, by assuring that the various
LUN traffic is isolated/fixed to one connection or another,until fail over
at the target.  These types of storage controllers will probably continue
to need Wedge Drivers, but that makes it very hard to come up with generic
Desktop and Laptop Initiators that can efficiently use those types of RAID
Arrays. IMHO it is unlikely that Microsoft will ship various vendor
specific Wedge Drivers, so it will be up to the RAID manufacture, and that
is always problematical in large installations.  [/Huff]

Also, some wedge drivers claim to utilize device proprietary features,
which a device independent iSCSI initiator layer could not provide
through "multiple connections per session".

[Huff] And again Correct, as I agreed above.  However, it would be very
good if the vendors that are making the various generic iSCSI initiators,
think through how they will handle the Single Connection case with one of
the above mentioned RAID Array Controllers, so that upon failure of one
side of a duplexed Raid Storage Controller, the Session can be restarted
from the initiator to the surviving side of the Raid Controller (which may
have a different TCP/IP address, or have taken over the failing IP
address).  If a clean new session is started, the target  still needs to
handle Persistent Reserves, and if the surviving Storage controller board
actually takes over the IP address, then I am not sure what we should be
doing since the surviving side may or may not have approprate state to
continue the session as if nothing had happen.  (I would be interested in
opinions here.)

In any event, as I suspected, we are in basic agreement, but were talking
past each other.  So the question is should David's suggestion about
including, in the Protocol Document, the concept of multiple ISIDs per
(i)SCSI Port.   My opinion is not, since it would probably cause a whole
lot of  discussion about Wedge Drivers, etc., and I do not think that would
be approprate in the iSCSI spec. [/Huff]

Regards,
Santosh