RE: iSCSI: ISID issue

["Somesh Gupta" <somesh_gupta@silverbacksystems.com>]

David,

If features such as multiple connections per session, or
session recovery, across multiple adapters is to work,
it would require the host software to have fine grained
control over the login process. These require that the
host software be able to ask the adapter to open
a new connection, and login with a specific ISID (& TSID),
and provide most operational parameters for the session.

If we think this feature is important & should be encouraged,
then we should go for a model that encourages the adapter
to provide the host software the ability to specify these
values.

If we think multiple connection per session, and session
recovery should be limited to a single adapter, then
maybe it is not so important for the host software to control
the ISID.

Somesh


> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Black_David@emc.com
> Sent: Friday, September 28, 2001 12:18 PM
> To: ips@ece.cmu.edu
> 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
> ---------------------------------------------------
>