RE: FW: iSCSI: "conservative reuse" requirement

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

Your assumption of what is meant by an initiator portal group is incorrect
(I don't think it's implied that IPG = IP???)  An initiator portal group is
the same concept as a target portal group - it's the collection of IP
addresses which can be combined to create a single iSCSI session.
Frequently this is thought of as an iSCSI HBA, but that is not necessarily
so, it could be a number of iSCSI HBAs, etc.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com 

> -----Original Message-----
> From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com]
> Sent: Monday, December 31, 2001 10:39 AM
> To: Jim Hafner
> Cc: ips@ece. cmu. edu (E-mail)
> Subject: RE: FW: iSCSI: "conservative reuse" requirement
> 
> 
> Regarding answer 2 below:
> There is no given definition for an iSCSI Initiator Portal Group (however,
> it is implied to be the same as the endpoint in 9.1.1, which would be the
> same as the SCSI Initiator Port). Since an iSCSI Initiator Portal Group is
> the same as a SCSI Initiator Port and since an iSCSI Target Portal Group
is
> the same as a SCSI Target Port, then each session in answer number 2 would
> not have a "different SCSI initiator port"; hence you would have a
parallel
> nexus.
> One thing that is not clear in section 9.1.1 (however, it is loosely
> implied) is that the reuse of ISID's applies to a given initiator endpoint
> (SCSI Initiator Port or what should be called an iSCSI Initiator Portal
> Group)). I think that should be made clear.
> What am I missing? Could it be that an iSCSI Initiator Portal Group is not
> equivalent to a SCSI Target Port?
> 
> Eddy
> 
> -----Original Message-----
> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
> Sent: Saturday, December 29, 2001 6:14 PM
> To: Eddy Quicksall
> Cc: ips
> Subject: RE: FW: iSCSI: "conservative reuse" requirement
> 
> 
> Eddy,
> 
> The SCSI initiator port is modeled as the endpoint of the 
> iSCSI session;
> the SCSI target port is modeled as the iSCSI target portal group.  The
> reason we did it this way was to allow more than one session 
> between portal
> groups by allowing multi-plexing of sessions with different 
> ISIDs from the
> same iSCSI initiator portal group to the same target portal group.
> 
> So, the answer to your questions are:
> 1) no, we're assuming no more than on session *with the same 
> ISID* to the
> same target portal group (that'd be more than one nexus), but 
> by allowing
> different ISIDs we get different SCSI initiator ports.
> 2) no, we're allowing more than one session between an iSCSI initiator
> portal group and an iSCSI target portal group (each session 
> has a different
> SCSI initiator port (id'ed by its ISID) but the same SCSI target port
> (id'ed by its portal group tag).
> 3) sort of, the ISID together with the iSCSI Initiator Name fully
> identifies the SCSI initiator port (and so defines the SCSI 
> initiator port
> name and the identifier).
> 
> Does that clear this up?
> 
> Jim Hafner
> 
> 
> "Eddy Quicksall" <Eddy_Quicksall@iVivity.com> on 12/28/2001 
> 07:19:33 PM
> 
> To:   Jim Hafner/Almaden/IBM@IBMUS
> cc:   "ips@ece. cmu. edu \(E-mail\)" <ips@ece.cmu.edu>
> Subject:  RE: FW: iSCSI: "conservative reuse" requirement
> 
> 
> 
> Due to 2.5.3 (b) "Between a given SCSI initiator port and SCSI target
> port, there can be only one I_T nexus (session)", aren't we always
> "assuming no more than one session"?
> 
> Or are you talking about more than one session between different SCSI
> initiator ports and a single SCSI target port?
> 
> Is the ISID equivalent to SAM-2's Initiator Port Identifier?
> 
> 
> Eddy
> 
> -----Original Message-----
> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
> Sent: Friday, December 28, 2001 12:15 PM
> To: John Hufferd; Eddy Quicksall; Mallikarjun C.; Black_David@emc.com
> Cc: ips@ece.cmu.edu
> Subject: Re: FW: iSCSI: "conservative reuse" requirement
> 
> 
> Folks,
> 
> Sorry for taking so long to jump into this discussion.
> 
> There are a number of issues raised in this thread:
> 1) should "conservative reuse" of ISIDs be made a MUST
> 2) does "conservative reuse" imply that all hosts look "single SCSI
> ported"
> 
> Here's my two cents (using "CR" as a shorthand for "conservative
> reuse")
> 
> I don't believe that CR needs to be a MUST.  The only time this has
> any
> real value is in configurations that use SCSI persistent reservations
> (and
> where new SCSI target reservation features are enabled -- NB.  these
> features are yet to be approved but are working their way through the
> process). I don't think these are going to be (even in the future) the
> majority of installations.  There are many ways then that CR could be
> something that is not generally available in most drivers but is added
> by
> configuration and perhaps even "value add" (:-{)).
> 
> In short, I don't see a strong case for this to be a MUST.  So, to
> David
> Black, my answer is that having a mechanism to enable this feature or
> have
> it as a "purchase requirement" is an acceptable mechanism to make sure
> the
> feature is there when needed, but it is need not be a requirement of
> the
> protocol.  To Mallikarjun, I think I'm agreeing with you that so long
> as
> there is a mechanism defined, iSCSI has done it's job.
> 
> As for the second issue (raised by Mallikarjun), let's look at the
> definition of CR.  What is means is that when an iSCSI initiator
> (node)
> creates ISIDs for use in session identifiers, it attempts to reuse
> them
> as
> much as possible with different SCSI target ports (iSCSI target portal
> groups).  This is the only way that a SCSI target or LU can see the
> same
> SCSI initiator port through two or more of its SCSI target ports --
> that
> is, that the target can determine multiple paths *from* the same SCSI
> initiator port.   But, the model for generating ISIDs is not really at
> the
> node level but at the initiator portal group level.
> So, IMO, the conclusion that all hosts must then look "single SCSI
> ported"
> is too dramatic.  As I mentioned,  ISIDs are conceptually generated
> within
> initiator portal groups (that's why we defined the mechanism for
> generating
> ISIDs).  The conclusion I draw is that (assuming no more than one
> session
> to any given target portal group), an iSCSI initiator implementing CR
> will
> have as many SCSI initiator ports as iSCSI initiator portal groups
> (independent HBAs?).  Each initiator portal group would generate one
> ISID
> (that is different from that generated by/for the other initiator
> portal
> groups) and use CR for repeatability.  [This is consistent with a
> model
> that mapped SCSI initiator ports to initiator portal groups, which we
> had
> to abandon because the "assuming no more than one session..." was no
> acceptable as a requirement!!!]  This independence of ISIDs for each
> initiator portal group allows each initiator portal group to open
> sessions
> with *every* target portal group it knows about without having to
> worry
> about interfering with other sessions. [This has shades of the
> "partitioning" rule for ISIDs that has been discussed ad nauseum!!!]
> 
> (I have a feeling that this note is not well composed -- it is the
> holidays, you know).  I hope I've addressed everyone's concerns and we
> can
> lay this one to rest.
> 
> Jim Hafner
> 
> 
> John Hufferd
> 12/25/2001 08:49 AM
> 
> To:   "Eddy Quicksall" <Eddy_Quicksall@iVivity.com>
> cc:   Jim Hafner/Almaden/IBM@IBMUS
> From: John Hufferd/San Jose/IBM@IBMUS
> Subject:  Re: FW: iSCSI: "conservative reuse" requirement  (Document
> link:
>       Jim Hafner)
> 
> You are correct.  The section was created by Jim Hafner, and via this
> note
> I will ask him if he could answer Mallikarjun Directly since I did not
> understand his issue.
> 
> .
> .
> .
> 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
> 
> 
> "Eddy Quicksall" <Eddy_Quicksall@iVivity.com> on 12/24/2001 06:06:44
> PM
> 
> To:   John Hufferd/San Jose/IBM@IBMUS
> cc:
> Subject:  FW: iSCSI: "conservative reuse" requirement
> 
> 
> 
> John,
> 
> Were you the author of "conservative reuse"? I am wondering about some
> issues. Maybe you could educate me somewhat ...
> 
> I started this subject in a different thread by saying that it may be
> good to make "conservative reuse" a MUST.
> 
> I got one objection from Santosh below. Then David Black picked it up
> by basically agreeing with me. Then Mallikarjun objected to that.
> 
> It seems like the objective would be to give targets a way to figure
> out that two or more sessions are coming from the same Initiator Port.
> That is needed support persistent reservations.
> 
> If an initiator does not use "conservative reuse", I don't think
> targets will be able to make that determination.
> 
> Comments?
> 
> Eddy
> 
> -----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
> > ---------------------------------------------------
> >
> >
> 
> 
>