Re: iSCSI: ISID issue

["Jim Hafner" <hafner@almaden.ibm.com>]

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
---------------------------------------------------