RE: iSCSI: ISID and the New Persistent Reservations Proposals

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

David,

A few (hopefiully final) comments in line.

Jim Hafner


Black_David@emc.com on 10/05/2001 06:52:59 pm

To:   Jim Hafner/Almaden/IBM@IBMUS, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: ISID and the New Persistent Reservations Proposals



Jim,

> My strongest discomfort is this:  in essence you are removing the SCSI
> Initiator Port Name from the iSCSI implementation of the model.  You're
> hoping to fill that gap later with a text key whose semantics have yet to
> be defined.

Having the text key semantics be "yet to be defined" seems reasonable
because the behavior required by T10 is in the same state.  Horse first,
then cart :-).
<JLH>
The behavior required by T10 is not "yet to be defined".  What is missing
is crossing a few t's and dotting a few i's to make the proposed new
behavior more backward compatible with existing implementations.  The
general model is defined, though not yet approved (but I think you can
expect something in the next 3 months).
</JLH>

> My expectation is that once you attempt to put the name back
> in you're recreated the OptionA/OptionB debate and will never
> be able to solve that satisfactorially.

I disagree.  ISIDs aren't negotiable, text keys are.  In the text key
situation analogous to the ISID situation that causes the OptionA/OptionB
mess, the Target can set the text key to some sort of "Port Identity
Conflict Detected" value and ship everything back to the Initiator
with no harm done.  Trying to do that sort of thing with ISIDs would
be a mess, as indicated by the amount of email on OptionA/OptionB.
<JLH>
I don't get this?  You're going to have the target "negotiate the value of
this key"?  We don't negotiate the value of the iSCSIName.  This would fall
under the same category (I would hope!).   Saying "conflict" for key=value
isn't any different from saying "conflict" for ISID.
</JLH>

> I'm concerned that removing the notion of SCSI Initiator Port Name
> from the model today, you will have strongly hindered iSCSI's ability
> to take advantage of a number of things that T10
> will be able to do, now that Names are part of the lexicon.

And I have a strong discomfort with designing for functionality that isn't
specified.  We already have a mismatch where the current T10 proposal #1
does not match current ISID specification (see below on conservative
reuse).
As T10 does things with the Port Name, we can put in the text key(s)
required
to make them work.
<JLH>
I don't see a mismatch, further comment below.
</JLH>

> I also believe as I've stated that the OS's are going to prefer to see
> a more stable SCSI port view of the initiator's ports than we're
currently
> anticipating in iSCSI.

As long as the TSID is not used to provide this view, there is no problem
here (e.g., the enumeration of interface cards on boot can be used).
<JLH>
Then I can use the enumeration for ISIDs as well, as I outlined.
</JLH>

> Finally, I think
>    - the reason to do this rather than the ISID is that it cleanly splits
>    persistent reservation management away from iSCSI session management.
> is a major violation of layering.  You're going to burden the reservation
> management with having to coordinate iSCSI actions.

I disagree. The interaction required is something that will have to happen
anyway if T10 adopts any proposal that has reservations span sessions at
the
Target.  Suppose that port X opens a session to port A, places a persistent
reservation that spans target ports, and then opens a session to port B -
as part of setting up that second session, port B has to interact with the
persistent reservation logic to discover that the reservation exists and
applies to the second session.  This is all that's required, and it's true
for any transport - in each cases the transport-specific port
identification
has to be passed from the transport to the SCSI reservation logic.  The
only wrinkle is that iSCSI gets this name from a text key instead of a WWN
or a parallel SCSI bus ID - at the SCSI level, this shouldn't matter (the
IDs are opaque and are being checked for equality).  In other words, if
there's a layering problem here, it's in SAM2 ...
<JLH>
The interaction I was talking about (which is what I thought you were
addressing) was in the OS side (not the target).  It was about having the
application that is coordinating the reservation passing key stuff through
the layers (within the initiator) to the iSCSI initiator layer to get this
key over to the target.

You had talked about the reservation application passing key=values down
through the layers for iSCSI to use for SCSI Initiator port identification
(or some such).  That's the layering I was referring to.

The target has always had to do some (minimal) cross port coordination.
The newer proposals in T10 will require more (but no more in iSCSI than in
any other protocol, except SPI where this proposal has no relevance).
</JLH>


> [I've argued that conservative reuse of ISIDs to different target portal
groups
> provides a clean consistent view of SCSI Initiator Ports to the upper
layers and
> that's all that's needed.]

But that requirement is NOT in the current draft, and inserting it would
impact implementation approaches such as that originally described by Nick
Martin in which an iSCSI implementation has to cons up an ISID in the
potential absence of coordination with other implementations that share
the same iSCSI Initiator Node Name.  The nasty problems result when there
are multiple Initiators connected to multiple Targets, but not all
Initiators
are connected to all Targets - an Initiator could set up several sessions
and only then discover that the ISID it used is taken and have to tear down
those sessions and start over.  This is why ISIDs as currently specified
aren't sufficient to deal with proposal #1 and changing them to do so would
be a visible technical change.
<JLH>
I disagree here.
(a) The current spec says what the ISIDs are used for and how they ought to
be generated (loosely).
(b) It does not make conservative reuse a REQUIREMENT, but it does suggest
reasons for that.
(c) Conservative reuse is NOT a requirement anyway (and I've never said it
is). It makes for some things being simpler.

I'm confused by your use of the terms "multiple initiators" and "multiple
targets".  Are we talking with the same iSCSI Name or different names?
This issue has nothing to do with three or more entities.  It is strictly
scoped between one iSCSI initiator (by name) and one iSCSI target (by
name).
</JLH>

> None of those are strong technical arguments however.
>
> I think we agree that the problem comes up because the belief that
> coordination of ISIDs on the initiator side is going to be difficult.
I'm
> not convinced that's the case, but let me try a different approach, which
> may make the implementation easier.

The summary is to have the OS enumeration provide the portal group tag,
and make that part of the ISID either explicitly or via a text key that
implicitly extends the ISID.  It's a good try, but I think it runs into
problems because device enumeration order in an operating system can
change between reboots for all sorts of reasons ranging from the
unavoidable (interface card fails in a fashion that causes it not to
be discovered on boot - this is discovery by plug-and-play logic or the
like, not iSCSI discovery) to the inane (stupid plug and play tricks,
new driver revisions).  This may wind up adding the Initiator Portal
Group number to the list of things that an Initiator has to remember
in order to get its persistent reservation state restored.
<JLH>
But this isn't a problem at all.  So things move around.  The only affect
this would have is on a persistent reservation of type #1 and in that case,
perhaps enough resets and reboots have occured to have clean up and cluster
recovery so that the problem isn't there.
</JLH>

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