Re: iSCSI: "conservative reuse" requirement

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

In regards to the first (the important) point you made.  Perhaps an example
would be best. (Since I think what I said is completely consistent with the
draft.)

Suppose the vendor "xxx" assigns the qualifier "1" to the SCSI Initiator
Port's ISID.  Then suppose the IANA Enterprise Number is 5. The name of the
SCSI Initiator Port then might be "main_node"+i+ISID where ISID is made up
of type= 1, vendor=5, qualifier=1. Or in other words ISID=0x010000050001.

So lets suppose the vendor had an HBA/Device Driver combo that assigns the
SCSI Initiator Port to be "main_node"+i+0x010000050001.  Now this same
Initiator Node Name and ISID can be used with every Session that is
connected via the Same HBA/Device Driver (which is in this case, the SCSI
Initiator Port).  They only thing it can not do is connect to the same SCSI
Target Port more then once.  If the iSCSI Initiator Node wants another
connection to the same SCSI Target Port it must establish another SCSI
Initiator Port and change the qualifier.  That means that the new SCSI
Initiator Port might be called "main_node"+i+0x010000050002.  Further,
every session that the new SCSI initiator creates will have the same name
SCSI Initiator Port Name.  This New SCSI Initiator Port can be via another
HBA/Device Driver, or even via the original HBA/Device Driver.

So it is possible for the Conservative Reuse to be used with a Single iSCSI
Initiator Node, yet have more then one SCSI Initiator Port each uniquely
defined, and with each having its own single ISID, which it uses for all of
its connections.  In this case  the iSCSI Initiator Node would have more
then one session to the same iSCSI Target Node, via the same SCSI Target
Port.

I think that is exactly what I intended to say in the previous note and is
consistent with the Version 9 of the Draft.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


"Mallikarjun C." <cbm@rose.hp.com> on 01/02/2002 06:12:32 PM

To:    John Hufferd/San Jose/IBM@IBMUS
cc:    <ips@ece.cmu.edu>
Subject:    Re: iSCSI: "conservative reuse" requirement



John,

>This is called Conservative Reuse
> since when we start/restart a session we are not choosing a different
ISID.

That doesn't seem to be what's meant by rev09 when it says in section
9.1.1 -
   " the same ISID should be used in the Login process to multiple
     target portal groups (of the same iSCSI Target or different iSCSI
    Targets)."
and further it says -
   "The principle of conservative reuse "encourages" reuse to other
    target portal groups. When a SCSI target device sees the same
    (InitiatorName, ISID) pair in different sessions to different target
    portal groups, it can identify the underlying SCSI Initiator Port on
    each session as the same SCSI port (in effect, it can recognize
    multiple paths from the same source)."

>The Name of the SCSI Initiator Port is made
> up of the iSCSI Initiator Node Name and the ISID.

Just a nit - also includes the letter 'i'!

> If those other iSCSI Initiators have HBAs which have been made by the
                                  same
                                  ^^^^^^^
Somehow it appears to me that this isn't "carefully qualified", :-)

Regards.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668
Roseville CA 95747


----- Original Message -----
From: "John Hufferd" <hufferd@us.ibm.com>
To: <cbm@rose.hp.com>
Cc: <Black_David@emc.com>; <ips@ece.cmu.edu>
Sent: Wednesday, January 02, 2002 4:57 PM
Subject: Re: iSCSI: "conservative reuse" requirement


>
> Mallikarjun,
> Comments in line between [Huff/] and [\Huff].
>
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Home Office (408) 997-6136, Cell: (408) 499-9702
> Internet address: hufferd@us.ibm.com
>
>
> "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 01/02/2002 01:21:13 PM
>
> Please respond to cbm@rose.hp.com
>
> Sent by:    owner-ips@ece.cmu.edu
>
>
> To:    Black_David@emc.com
> cc:    ips@ece.cmu.edu
> Subject:    Re: iSCSI: "conservative reuse" requirement
>
>
>
> Now that I'm back from vacation, let me offer some (delayed)
> comments on this.  I also read Jim's reply where he appeared
> to mostly agree with me.
>
> >...as long as it presented
> > each of them to all target ports...
>
> I disagree with your assumption that an initiator must
> "present" *all* its ports to every target port in a target
> device.  Each distinct initiator port (signified by a unique
> ISID) may want to talk to only one target port (i.e. one portal
> group) - that's a typical usage of multi-HBA (i.e. multi-port)
> hosts talking to multi-FC port targets today.  As far as I
> can understand, a mandatory "conservative reuse" would
> preclude this usage.  Please comment if your visualization
> of conservative reuse is different.
>
> [Huff/]
> We have now fallen into the problem that Jim, Julian, Marjorie, and I
spent
> the Holidays exchanging e-Mails about.  You use the term Initiator to
> represent the Total Initiator Node (and indeed our draft definitions
> encourage that view).  However, some others, when they talk, use the SCSI
> interpretation of the word Initiator, which is the SCSI Initiator Port.
So
> as Marjorie has clearly pointed out to me, I need to be more precise, and
I
> think the rest of us also.  We need to fully qualify the term Initiator
> when we use it, in these types of discussions.  We need to say iSCSI
> Initiator Node, or SCSI Initiator Port etc.  So let me try that below, in
> hopes of perhaps clearing up some concepts.
>
> The use of Conservative Reuse applies to the how the Name of the SCSI
> Initiator Port will be chosen.  The Name of the SCSI Initiator Port is
made
> up of the iSCSI Initiator Node Name and the ISID.
>
> We are attempting to ensure that any one SCSI Initiator Port will not
pick
> various different ISIDs in a manner that will prevent the Persistent
> Reserves from being reestablished across a Session Restart.  To do that
we
> strongly suggest that the Vendor follow the Type and Vendor ID approach
to
> creating and ISID as specified in version 9 of the Draft. Also they
should
> pick the 16 bit Qualifier part in a way that will usually be the same
> number each time a Session from that SCSI Initiator Port is restarted.
The
> easiest way to do this is for the iSCSI Process to Identify the SCSI
> Initiator Port with the same ISID Qualifier every time an iSCSI Session
is
> started with any SCSI Target Port (via its iSCSI Target Portal Group).
>
> When this is done, everything works.  This is called Conservative Reuse
> since when we start/restart a session we are not choosing a different
ISID.
>
> Please note I did not restrict the actions of any other SCSI Initiator
Port
> within the iSCSI Initiator Node.  They can each have their own ISID and
use
> the iSCSI Transport to connect to what ever SCSI Target Nodes they wish.
> If those other iSCSI Initiators have HBAs which have been made by the
same
> vendor (and if that vendor does not support Multiple Connections per
> Session across the HBAs), it is the Vendors responsibility to chose an
ISID
> Qualifier for its second (and subsequent) SCSI Initiator Port, which does
> not conflict with the first one.  When done correctly, then if by chance,
> the second SCSI Initiator Port connects to the same SCSI Target Port to
> which the First one connected, they will each be seen, by the Target, as
> different Sessions from different SCSI Initiator Ports and things are
> completely legal.
>
> In this case, as it is in Fibre Channel, the Host (iSCSI Initiator Node)
> will have to be very careful how work is handed out to the different SCSI
> Initiator Ports, so that Work arrives in the correct order and there is
no
> conflicts with Reserves.  (The process that does that balancing between
the
> HBAs is what, in Fibre Channel, we have called a Wedge Driver).
>
> So what I have said above, is that when we carefully qualify the Term
> Initiator, we can see that Conservative Reuse does NOT cause any
> restrictions on the way we use the Sessions within an iSCSI Initiator
Node.
> [\Huff]
>
> OTOH, I can see that the ability of *one* initiator SCSI
> port to establish nexii with multiple target SCSI ports in
> a target device is highly desirable (perhaps even T10-required
> shortly).  IMO, iSCSI had already met this need by defining
> and enabling "conservative reuse", and that's where we should
> stop.  I would actually advocate wording along the lines of -
>
>     "When a given initiator implementation seeks to present
>      a single SCSI port abstraction to multiple target portal
>      groups (thus multiple SCSI target ports) of an iSCSI target
>      node, conservative reuse is the means to realize it.
>      Conservative reuse hence MUST be used in this case."
>
> and leave it at that.
> --
> Mallikarjun
>
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668     Hewlett-Packard, Roseville.
> cbm@rose.hp.com
>
>
> Black_David@emc.com wrote:
> >
> > Not exactly.  "Conservative Reuse" would allow an initiator
> > to present multiple initiator ports, as long as it presented
> > each of them to all target ports (assuming that the connectivity
> > exists).  Why would an Initiator want to present different
> > ports to different target portal groups?  I don't think there's
> > another example in which SCSI behaves this way in practice.
> >
> > --David
> >
> > > -----Original Message-----
> > > From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> > > Sent: Monday, December 24, 2001 12:47 AM
> > > To: Black_David@emc.com
> > > Cc: ips@ece.cmu.edu
> > > Subject: Re: iSCSI: "conservative reuse" requirement
> > >
> > >
> > > > I think this is headed towards "conservative reuse" being a MUST if
> > > > we're serious about support for shared persistent reservations.
> > >
> > > Mandating "conservative reuse" appears to force initiators to
> > > always act
> > > as a single initiator port (wrt one target; assuming only one
> > > session as an
> > > example) per initiator device - which rules out the case of
> > > an initiator
> > > intentionally wanting to present a different port to each
> > > target portal group.
> > >
> > > IMHO, if iSCSI provides an architected mechanism to support shared
> > > persistent reservations ("conservative reuse"),  that should
> > > be completely
> > > adequate to meet the expectations to be a legal SCSI protocol.
> > > --
> > > Mallikarjun
> > >
> > > Mallikarjun Chadalapaka
> > > Networked Storage Architecture
> > > Network Storage Solutions Organization
> > > Hewlett-Packard MS 5668
> > > Roseville CA 95747
> > >
> > > ----- Original Message -----
> > > From: <Black_David@emc.com>
> > > To: <santoshr@cup.hp.com>
> > > Cc: <ips@ece.cmu.edu>
> > > Sent: Friday, December 21, 2001 4:50 PM
> > > Subject: iSCSI: "conservative reuse" requirement
> > >
> > >
> > > > Santosh Rao writes:
> > > >
> > > > > I am opposed to the suggestion that "conservative re-use"
> > > of ISIDs be
> > > > > made a MUST. This is really only required when initiators
> > > need to be
> > > > > using the new T10 Reservation scheme that can be shared
> > > > > across initiator ports.
> > > >
> > > > Those reservations are a Target feature.  With this
> > > approach, the ability
> > > > to use the target feature depends on details of the initiator
> > > > implementation.
> > > > More below ...
> > > >
> > > > > For those initiators that don't care about this type of
> > > reservation,
> > > > > conservative re-use is of no use and initiators may like to
assign
> > > > > ISID's in a per-initiator node fashion, thereby, being
> > > able to use these
> > > > > ISIDs as a lookup index for the sessions on that initiator node.
> > > > >
> > > > > Hence, I suggest that "conservative re-use" be worded as
> > > > > "encouraged to use" or something to that effect, but not MUST
USE.
> > > > >
> > > > > Comments ?
> > > >
> > > > The "initiator" is more than one entity.  The iSCSI HBA/NIC
> > > and driver
> > > > doesn't know whether shared persistent reservations are
> > > being used and
> > > > shouldn't have to care - they're just more SCSI commands to
> > > transport.
> > > > Some other entity (e.g., clustering software) will be generating
the
> > > > shared persistent reservations.  This raise the possible scenario
> > > > involving a target that supports the new shared persistent
> > > reservations
> > > > and an entity that wants to use them.  The entity detects
> > > (via SCSI means,
> > > > e.g., something in a mode page) that the Target supports
> > > shared persistent
> > > > reservations, tries to use them, only to discover that they
> > > don't work
> > > > because the iSCSI HBA/NIC doesn't implement "conservative reuse".
> > > >
> > > > I'm worried about this causing both interoperability issues
> > > and possible
> > > > T10 issues -- from a T10 viewpoint, if shared persistent
> > > reservations
> > > > don't work, the initiating entity should have some SCSI-level means
> > > > of determining this ... if that means exists only on the Target,
the
> > > > above scenario is iSCSI's problem (Target can't query Initiator to
> > > > determine whether it does "conservative reuse"), and having
> > > a separate
> > > > initiator side means that the entity has to check only for
> > > iSCSI (and
> > > > not for any other SCSI transport) does not seem like the right
> > > > approach.
> > > >
> > > > I think this is headed towards "conservative reuse" being a MUST if
> > > > we're serious about support for shared persistent reservations.
> > > >
> > > > Comments?
> > > > --David
> > > > ---------------------------------------------------
> > > > David L. Black, Senior Technologist
> > > > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > > > +1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
> > > > black_david@emc.com         Cell: +1 (978) 394-7754
> > > > ---------------------------------------------------
> > > >
> > > >
> > >
>
>
>
>