iSCSI - SID building

["Julian Satran" <Julian_Satran@il.ibm.com>]

I am amazed by the amount of debate that is always generated by the
selection of a unique identifier.
It must be something deep in human nature.

I would like to start this relatively long note (long by my standards) by
stating than any change
in the SID structure will have little impact on the iSCSI draft text and
probably will affect implementations only in a very limited way.

The SID is almost entirely hidden in the protocol and is used only to:

   signal that a new connection belongs to a SID
   through a part of it (or its entirety) to signal that the initiator
   wants to assume ownership on whatever persistent state was associated
   with  it during a "previous life"


The SID is the element that differentiates one session from another between
a given pair (initiator and a target).

In choosing how to generate a unique SID we had three choices:

   the initiator generates the SID
   the target generates the SID
   the initiator generates a part and the target generates a part


The current draft is using option 3.

Let us try and examine the  pros and cons of all the options.

In generating a unique identifier that has a limited life-span one has to
consider two elements - the ease by which it is generated and how difficult
it is to recycle it.

A unique identifier is easy to generate if the generating element is unique
( a single HBA, a monolithic OS or application space) or its domain can be
statically partitioned.

If you consider iSCSI neither of those conditions is met by all the
initiators and targets although the initiators
are more likely to have a simpler structure (hardware and on average) than
targets (we will more likely see simple initiators connect to complex
targets than complex initiators connect to simple targets; by
simple/complex I mean multi HBA).

For identifier reuse you have to recall that SID (or part of it) are used
by initiators to identify themselves to targets
to reclaim "persistent rights" like reservations. As such initiators have
all the information needed to reclaim an ID while targets must do some
guesswork (complicated somewhat by the fact that some persistent rights are
not explicitly bound).  Initiators know if they want something related to
the ID or not and if not it can be reclaimed.
Note also that any "static" ID partitioning between target HBAs may be
upset at "reconnect" time (I might have a SID allocated by HBA1 and
reconnect with it later - to regain my reservations - to HBA2).

Targets may register SID or parts of it to identify the owner of a
persistent right but they don't need to do any
reclaiming operations on rights (those are explicitly cleaned by SCSI
commands).

All the above rationale may suggest that the best place to generate a SID
is the initiator.

However initiators tend to be less reliable (an eufemism) than targets.
To cope with this we have again 3 choices:

   (a)Extreme-attitude - any initiator that is less than perfect will not
   fit our world model and everything running on it will not work
   (b)Move the SID allocation to the target
   (c)Split the allocation into a safe part (the target assigned TID) and
   an unsafe part (the IID) but contain the harm to nonconforming parts of
   the initiator


I view of all the above I think that the scheme we have today is a sound
choice.

If many of you feel that the choice is not good, or there are some other
choices I suggest we return this item to the Naming&Discovery team (the SID
is a dynamic extension of the name) for further consideration.

Again protocol will not be affected in a major way by the result of this
debate and neither will it solve the issue of bad initiator components
(that triggered the whole debate).

Julo