Re: iSCSI: ISID issue

[Santosh Rao <santoshr@cup.hp.com>]

David, John, Jim  & All,

Before we go down the path of attempting to select a different rule for
the creation of initiator ports, I would like to request the group to
take another look ath Jim's ISID scheme.

I think comparisions to FC's mess-up of the node WWN are not fair to the
current ISID rule, since, unlike in FC, the worst case scenario with the
ISID rule, is that each iscsi driver on the system will take up a
different iscsi initiator name.

In most O.S.', there will be 1 or perhaps 2 or maybe a few in the worst
case( < 5 - 6 ?), operational iscsi drivers functioning actively on that
system. Thus, we're really looking at an ideal goal of 1 initiator name
being diluted to perhaps, 1 initiator name per iscsi driver active on
the system. I don't think this is too bad and is not comparable with FC,
where each HBA takes a different node name.

Given that all iscsi HBA vendors will need to have SOME host O.S. driver
component which they will be writing, it is possible for them to hand
out ISIDs to their adapters within their own driver domain. The ISID
rule works fine as long as ISIDs are ditributed within the domain of
each iscsi driver and since, the number of iscsi drivers supported on an
O.S. are'nt going to be that large, I think, this is'nt as big an issue
as FC's node name problems.(which scales linearly with the number of
HBAs, not the number of drivers).

I support Jim's efforts on the "ISID rule" and think it is a reasonable
expectation, given that, we decided to support Multi-Cxn/Session and
thereby, got burdened with the "virtual SCSI port" concept.

Thanks,
Santosh



Jim Hafner wrote:
> 
> John,
> 
> Without burning too many cycles, my first thought is "I can't imagine what
> rules to impose".  As I said in the note, the initiator may have specific
> reasons for doing certain things (identifying itself in special ways), but
> the target has now way of knowing them.  So, I can't the the basis for any
> such rules.  The only rule at all would be "not two duplicate SSIDs to the
> same initiator", but that doesn't gain anything.  You could say the target
> is "allowed" to do certain things, but there is no motiviation for it to do
> so (so it probably won't).
> 
> Jim Hafner
> 
> John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 09/28/2001 05:19:58 pm
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> To:   Jim Hafner/Almaden/IBM@IBMUS
> cc:   ips@ece.cmu.edu
> Subject:  Re: iSCSI: ISID issue
> 
> OK, Jim, lets play this out.  You have been suggesting some rules for the
> Initiator Side, I bet you can come up with approprate rules for the Target
> side assignments. Right?  What do you think they would need to be?
> 
> .
> .
> .
> 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
> Internet address: hufferd@us.ibm.com
> 
> Jim Hafner
> 09/28/2001 04:51 PM
> 
> To:   John Hufferd/San Jose/IBM@IBMUS, ips@ece.cmu.edu
> cc:
> From: Jim Hafner/Almaden/IBM@IBMUS
> Subject:  Re: iSCSI: ISID issue  (Document link: John Hufferd)
> 
> John,
> 
> On the surface, what you're proposing (having the target name the SCSI
> Initiator Port) at least gives the port an identity.  But I wouldn't call
> it a name (persistent, immutable, etc).  Besides, the target has no vested
> interest in reusing the ISID (and some resource issue in not).  The
> initiator on the other hand may have a lot of reasons to "show the same
> face" for its side.   The "kicker" is one of those reasons.  The target can
> always use different ISIDs and never have to worry about support for the
> "kicker".
> 
> Jim Hafner
> 
> John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 09/28/2001 03:39:24 pm
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> To:   Jim Hafner/Almaden/IBM@IBMUS
> cc:   ips@ece.cmu.edu
> Subject:  Re: iSCSI: ISID issue
> 
> Jim,
> You might consider the thing that passes out the ISID  to be on the Target
> side.  You folks all yelled at me about my manic desire to have the target
> assign both the ISID and the TSID, and saw no  reason why we should not
> just call it SSID or SID.  But let me try it again, and see if it helps
> this model.  Suppose, in addition to the Target setting the TSID as it does
> today, it also assigns the ISID.
> 
> Now since the Session is not established until we go into Full Featured
> Mode (before that it is only a connection), all you have really done is
> move the routine that you described as assigning the ISID,  to a remote
> location.  The Full Initiator session name (made up of the iSCSI Node Name
> and ISID) is technically established before there is a session.  So it
> should be the same difference as far as your model goes, but you would have
> to keep the ISID as a separate item not just as a Target assigned SID.
> 
> Does that seem right to you?
> 
> .
> .
> .
> 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
> Internet address: hufferd@us.ibm.com
> 
> Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 09/28/2001 02:41:03 PM
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> To:   Black_David@emc.com, ips@ece.cmu.edu
> cc:
> Subject:  Re: iSCSI: ISID issue
> 
> David,
> 
> See my reply to your other note on the "kicker" thread.  But I have a
> comment here too.
> 
> Regardless of how we go about this 'who assigns the SSID' question, we
> still have a fundamental question about what to map the SCSI Initiator Port
> to AND what its 'SCSI Initiator Port Name' should be.  WIthout an initiator
> generated (or owned) name, we can't have such a beast (we can have SCSI
> Initiator Ports, but no name can be associated with them).   That will
> prevent iSCSI from being able to take advantage of things that SCSI has so
> far and will in the future better enable because of persistent named
> initiator ports.
> 
> The ISID was the most obvious thing to choose.
> Take that away and the whole thing has to get stirred up again.
> 
> I sympathize with the issue of configuration.
> However, if we can't solve the iSCSI Initiator Name (IIN) problem (and
> avoid the FC Nodename debacle), then it's true that configuration of ISIDs
> will also be a problem.
> I was expecting that we can solve the IIN problem by defining at least a de
> facto standard that could be put in place today.  I was hoping (perhaps
> naively) that we could solve the ISID allocation problem at the same time.
> The whole point of stating all this up front now was in hopes of 'learning
> from the FC mistakes'.
> 
> Let me add that (from private discussions) I've come to realize that the
> current wording is perhaps not exactly reflective of the real requirement
> for ISIDs.
> 
> The current wording says "partition". Some have come to interpret that as a
> static (once at boot, sort of) partition. That actually goes too far.  What
> is really needed (from the model point of view) is a service in the iSCSI
> Node that allocates ISIDs for use by session creators in the initiator
> portal groups.  Whether that is implemented passively by static
> configuration (static partition) or by dynamic partition (partitions can be
> reconfigured on the fly) or by an api to allocate on demand (on-line
> algorithm) - doesn't really matter.  The relevant point is that something
> (at the node level) has to pass them out for use in session creation within
> the portal groups *in such a manner so as not to break the ISID RULE*.  The
> static partition was one implementation that I thought was doable today.
> 
> Perhaps such a service is untenable.  If so, then I don't know that we can
> put any weight in the model to the notion of an iSCSI Initiator Node!  If I
> can't have that simple function, there can't be any more complex functions
> like failover, error recovery, etc..
> 
> In any case, there is still open (as far as I know) the issue of "what
> happens if a parallel nexus is attempted" (regardless of the definition of
> SCSI Initiator Port).
> 
> Jim Hafner
> 
> Black_David@emc.com@ece.cmu.edu on 09/28/2001 12:17:43 pm
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> To:   ips@ece.cmu.edu
> cc:
> Subject:  iSCSI: ISID issue
> 
> Attempting to pick this back up, and selectively quoting from
> the (extensive) email on this topic, here's where I think we
> are on this.  The issue is whether to eliminate ISIDs, so that
> iSCSI sessions are identified solely by target-assigned TSIDs.
> 
> The underlying concern is reliability of coordination of ISIDs
> among independent iSCSI implementations that make up a single
> iSCSI Initiator (one iSCSI Initiator Name), as originally stated
> by Nick Martin:
> 
> > In particular this enables independent agents within the same initiator
> to
> > attempt a login without knowing all ISIDs in use by other agents.  Each
> > agent would know the ISID of sessions it had successfully established,
> but
> > not the ISIDs for sessions established by others.  It can use the ISIDs
> it
> > knows to recover sessions it owns.  If an agent gets a failure attempting
> to
> > establish a new session, it would pick a different ISID and retry (or
> just
> > quit), rather than disrupting a session of another agent.
> >
> > I have a big problem with A) where independent agents must know the ISIDs
> > established by others in order to do no harm.
> 
> There have been a couple of attempts to address this by requiring
> ISID coordination to be done via administrative or OS means, and
> allowing arbitrary failures when it is not done correctly.
> Unfortunately, these attempts have failed to distinguish between
> incorrect/buggy iSCSI protocol implementations (which can cause
> all sorts of problems and arguably deserve whatever bad results
> they get) and administrative errors such as mis-entering a config
> parameter or miscopying a parameter from a hand-written configuration
> sheet (for which there is benefit in limiting the damage that results,
> as we can expect such errors to occur no matter how carefully
> iSCSI and its management tools are implemented).  The first
> attempt was to mandate a management interface - Jim Hafner wrote:
> 
> > ... mandate a management interface for setting/configuring ISID
> > partitions and the problem goes away of non-cooperating HBAs.
> 
> We can definitely mandate the existence of such an interface (actually
> ISID configuration interfaces for each iSCSI implementation), but we
> cannot mandate their correct use in all circumstances.  We could decide
> that it's ok for minor mistakes in using that interface to result in
> major damage, but that may not be the best design approach.
> 
> The second attempt was to strongly encourage automatic configuration
> mechanisms in OS platforms - Jim Hafner wrote:
> 
> > The whole reason we put in the draft the "SHOULD partition" ISIDs among
> > portal groups and why it is so prominent is to get all the people
> building
> > these components to agree NOW to the OS-specific mechanisms to achieve
> it.
> > First recognize the need and THEN to define the mechanism (and I've said
> > that the mechanism isn't hard, we (as vendors, not necessarily within the
> > specification) just have to agree on it).
> 
> Much as I believe iSCSI is important, I think this is essentially an
> exercise in wishful thinking - the "SHOULD partition" warning seems akin
> to firing a BB pellet across the bow of an aircraft carrier - it will
> likely be ignored.  I don't think iSCSI is in a position to drive this
> sort of change into existing OS device driver infrastructures - rather
> I think it's incumbent upon us to make sure that it can exist cleanly
> within them.  Jim goes on to say:
> 
> > We're trying to prevent exactly the problem David (I think) mentioned
> with
> > FW Nodenames never taking on the role they should have.  We're posting
> > right up front an implementation (strong) recommendation to enable both
> > assignment of Initiator Name (from outside the HW or SW) and of ISIDs
> (from
> > outside the HW or SW).   This enables the protocol to function at its
> best.
> > If people don't want to implement to this recommendation, then they'll
> pay
> > the price with either  inter-vendor interoperability problems (not with
> the
> > wire but within a given initiator) or with much more complex management
> > issues (a la FC Portnames).
> 
> And I'm concerned that having failed to learn from the Fibre Channel
> history, we may be condemned to repeat it.  The cross-HBA interfaces to
> coordinate the Node WWN never came into existence despite the best
> intentions
> and efforts of those involved in Fibre Channel, and they would have been
> no more complex than the ISID coordination (e.g., find all the possible
> Node WWNs, pick the numerically smallest).
> 
> An issue has been raised about why the Target is better suited to assign
> session IDs than the Initiator.  I've seen at least two good answers to
> this - Eddy Quicksall points out that this is fundamentally about managing
> Target-controlled resources:
> 
> > Now, I'm wondering why we are even trying to use the ISID to reset a
> session
> > when we should be using the TSID ... because the target can produce
> unique
> > TSIDs and use that to identify the session much more easily than using
> the
> > combination of InitiatorName and ISID.
> 
> And Sandeep Joshi points out that Targets tend to have a single entity
> controlling their entire implementation, unlike Initiators:
> 
> > ..the target may not be monolithic
> > but one assumes it would atleast be "monogenic" (single-vendor)
> > thereby enabling it to disallow multiple nexuses being
> > started with the same <initiatorName,ISID>
> >
> > The monogenic property may not hold for initiators so
> > a scheme which works without HBA cooperation is preferred
> > over one which requires cooperation.
> 
> I think Jim Hafner's "kicker" issue of T10 changing reservations to be
> associated only with SCSI Initiator Ports is a major problem for iSCSI
> *independent* of whether ISIDs exist or not -- I don't think keeping ISIDs
> in their current form is sufficient to address that issue and may in fact
> be the wrong way to go about it, as I'll explain in a separate message.
> I now believe this issue to be orthogonal to whether ISIDs remain, but
> folks will have to read that separate message to see whether they agree.
> 
> So, after reviewing all the email on this, I definitely don't see
> consensus on whether to keep ISIDs, but I'm seriously concerned
> that we are repeating the mistake Fibre Channel made with Node Names
> and will suffer the resulting consequences - iSCSI Initiator Names
> will get bound to HBAs rather than OS images in order to make absolutely
> positively sure that ISID conflicts cannot happen.
> 
> At the risk of starting yet another long discussion, comments?
> --David
> 
> --------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################