Re: iSCSI: ISID issue summary

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

... and have as much chances to blow a session as ISID.

Julo

Jim Hafner/Almaden/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu 10-10-01 16:27 Please respond to Jim Hafner

To:        Black_David@emc.com, ips@ece.cmu.edu         cc:                 Subject:        Re: iSCSI: ISID issue summary

David,

An excellent summary of the issues.

A couple of things I want to point out about the "text key" proposal, however.
a) The proposal sounds to me like iSCSI will have "optional SCSI Port names". Only when the key is used is the SCSI port named and when the key is not used, there is no such name. That's probably an acceptable situation as far as SAM-2 is concerned, but it certainly is odd.
b) The proposal would require at least as much coordination above the "session manager" level as managing ISIDs, though admittedly, it need not be implemented in all cases.
c) I'm concerned how to describe the model when names are optional, so as to avoid the parallel nexus problem. Is it that all initiator session endpoints that don't provide this text key have *implicit* unique names and only when the text key is presented does the name get explicit (and then possibly not be unique)? In that case, the key would have to be supplied in login next to the InitiatorName.

Jim Hafner

Sent by: owner-ips@ece.cmu.edu

To: ips@ece.cmu.edu
cc:
Subject: iSCSI: ISID issue summary



For those who haven't been following the long intricate
email discussion between Jim Hafner and myself, let me
try to explain the issue.

SCSI architecture (SAM2) is based on an intuition that SCSI
ports are fixed (e.g., physical) things that have names.  So
far, the existence of the names has been an intellectual
curiosity as they haven't mattered to any visible SCSI
functionality.  Single port Initiators predominate in
both Parallel SCSI and Fibre Channel (e.g., a dual ported
Fibre Channel HBA is usually treated as two SCSI Initiators,
not a single dual-ported one).

Jim tells us that T10 is about to define persistent reserve
functionality that depends on the identity of the SCSI Initiator
Port - in particular that under some circumstances, persistent
reservations will be associated with the Initiator Port independent
of the Target Port.  Persistent reservations are currently bound
to the Initiator Port and Target Port (as well as the LU they
affect).  For the rest of this message, I'm going to assume
that we want to support this functionality.  Assuming this and
that I got the description in this paragraph right ...

... I need to take a slight detour into pragmatics.  Those
who configure storage networks rapidly discover the value
of consistency and matching configurations.  Multi-path I/O
configurations tend to want to see access to the same set of LUs
consistently across a set of interfaces (i.e., Ports).  Between
suitable configuration and the aggressive setup of connections
to all possible targets, all the required connections come into
existence as part of the boot process.  Applying
this experience to the new persistent reservation functionality,
one would expect persistent reservations that are bound only to
an Initiator Port to be independent of the Target Port, in that
the reservation should span connections to all of the relevant
Target Ports and those connections should come into existence
as part of the boot process.

Turning to iSCSI, the situation gets complicated by the
interaction of two factors:
- Parallel sessions are permitted down to the interface
level (e.g., more than one iSCSI session may exist
that uses IP addresses A and B to connect iSCSI Initiator
I to iSCSI Target T).
- SCSI disallows parallel nexii (i.e., more than one session
between the same two SCSI Ports).
If SCSI Ports are mapped to hardware entities such as network
interfaces in iSCSI, the opportunity for parallel sessions
between the same pair of network interfaces vanishes.  In order
to avoid that outcome, iSCSI Initiator Ports have to be
mapped to software entities. To date, the ISID has been
used to identify those software entities, and the only rule
on their allocation is:

   ISID RULE: Between a given iSCSI Initiator and iSCSI Target Portal
   Group (SCSI target port), then can be only one session with a given
   ISID (identifying a SCSI initiator port).  See 3.12.8.

In order to get the expected outcome of the new functionality
being defined by T10, the same ISID has to be used to establish
all the connections that the persistent reservation is supposed
to span.  Unfortunately, that's above and beyond what iSCSI
requires - the relevant text about doing this in -08 is:

      The "ISID rule" does not preclude
      the use of the same ISID from the same iSCSI Initiator with
      different Target Portal Groups on the same iSCSI target or
      on other iSCSI targets

"does not preclude" is rather weak language for something that's
essential to making a piece of SCSI functionality work.  If an
iSCSI implementation uses a different ISID for every session
(which is also not precluded by the current text), then persistent
reservations will never span Targets or Target Ports for that
implementation despite T10's best efforts and intentions.  IMHO,
allowing that outcome is *wrong* (and this is the source of the
difference of opinion between Jim and myself).

The correction to this involves what Jim has called "conservative
reuse" of ISIDs.  This is something like for each ISID that an
implementation uses, a connection with that ISID is made to
every possible Target Portal Group of every possible Target.  I
suspect a longer explanation than this will be needed, including
a discussion of the desirability of avoiding a situation in which
the same ISID is used by two iSCSI implementations that are part
of the same Initiator and set up sessions concurrently.

IMHO, if we want to support persistent reservations at this stage
that span target ports, we need to replace the "does not preclude"
language with a REQUIREMENT for conservative reuse to avoid a
situation in which SCSI functionality that works consistently with
other transports works inconsistently with iSCSI (i.e., doesn't
work with iSCSI implementations that don't do conservative reuse).

Stepping back from the assumption that support for port-spanning
persistent reservations is required, I observe that the conservative
reuse rule impacts all implementations, even those that will never
use such persistent reservations because ISID is a mandatory part
of the iSCSI protocol.  If a text key were used instead, only those
Initiators that want to support this functionality on which T10
is "crossing a few t's and dotting a few i's" are affected (the
text key is optional).  The text key would be subject to a
conservative reuse rule similar to the one that would be needed
for ISIDs, and once T10 finishes the i's and t's, we can precisely
reference the SCSI features (persistent reservation expansion)
that require use of this text key.

In addition, text keys have much better alternatives for dealing
with conflicts than ISIDs - if a text key conflicts, it is possible
to continue  the negotiation with a different text key, whereas
ISID conflict is fatal to one of the two sessions involved.
As Jim has previously observed, changing the text key (e.g.,
generate a large random number in response to a conflict),
results in a situation that can be dealt with by software that
uses persistent reservations, although this departure from
conservative reuse should only occur as a consequence of some
sort of configuration mistake or bug.  At the tail end of this
reasoning chain is the observation that use of this text key
leaves the ISID without value/purpose, and hence would call
for its removal (or perhaps designation as a reserved field).

Putting on my WG chair hat for a moment, I can accept either
alternative outlined above:
- Add conservative reuse to the ISID rule.
- Use a text key for iSCSI port identification.
But I'm not comfortable with the current situation in which iSCSI
implementations are permitted to break T10-defined SCSI features
that will work as expected in other SCSI transports.

I hope this now makes sense to more people than just Jim and I,
and I apologize for the length of this message, as this is a
somewhat subtle issue.

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