Subject: RE: iSCSI: login issue - partial consensus call

From: "Jim Hafner" <[email-masked]>
Date: Thu, 6 Sep 2001 08:09:56 -0700

Folks,

Though I'm getting ready to throw in the towel on this issue (mostly
because it isn't really worth the fight), I want to state again my rational
for not supporting Option B.

Option A is the simplest for everyone.

Option B has much more complexity and is subject to the same results as
Option A if the C bit is used indiscriminantly.  How use of the C-bit is
controlled is actually outside the scope of the standard because
enforcement of requirements is by the receiving end of the protocol and
there's nothing for the target to do in this case.  The target can't say "I
don't think you really meant that".  A "good" initiator will never set the
C bit unless it really wants it and understands the consequences.  A "bad"
initiator (because of bad programming) will set the C bit first and then
handle the rejection as a retry (but when there is no rejection, the bad
effects have already happened).   A "good/bad" initiator may not set the C
bit first, but then set it after a rejection because it thinks it owns the
ISID space (e.g., doesn't even know or care that there might be another HBA
around) -- and we all know systems that behave this way!

The net of this is, in my opinion, that what we're trying to protect
against with Option B won't really be protected, so why bother with the
extra protocol.

And in reply to David's suggestion for a mandatory management interface to
disable the C-bit. If iSCSI can mandate that, then it can mandate a
management interface for setting/configuring ISID partitions and the
problem goes away of non-cooperating HBAs.

Jim Hafner

[email-masked]@ece.cmu.edu on 09/06/2001 07:10:37 am

Sent by:  [email-masked]

To:   [email-masked], [email-masked]
cc:
Subject:  RE: iSCSI: login issue - partial consensus call

Trying to close this issue, I think Nick's points are valid and
answer the question about when the "C-bit" would not be set --
when the entity sending the command suspects (or wants to protect
against) a problem in ISID assignment.  That appears to make option
B) the right choice:

       B) Should iSCSI mandate making this intended cleanup explicit
          by setting a bit (Say C-bit, for Clear) in the Login Command
          PDU to prevent an accidental session cleanup with a buggy
          initiator code?

I have the following additional comments:
(1) A new bit is needed.  Reuse of the X-bit for this purpose has been
     rejected by rough consensus of the WG.
(2) In order to deal with the worst case, every iSCSI implementation
     MUST have an administrative interface that can prevent this new
     "C-bit" from ever being set, even if the implementation thinks
     that setting it is the right thing to do.  This provides a
     way to deal with situations in which sessions are getting
     stomped on by ISID problems.
(3) Some additional words about ISID usage are needed to encompass
     scenarios in which ISID assignment is not present, does not
     assign enough ISIDs, or fails for some reason.

Comments are welcome.  Further objection to B) needs to explain
why Nick's scenarios should not be considered.  I was disappointed
to see a prior statement that the ISIDs would be different "by
definition" - this is in the same category as saying that software
and protocol implementations are bug-free "by definition".  Keep in
mind that Nick is correct in saying:

> The problem is that iSCSI does not and will not specify how two HBAs
> from different vendors installed in the same Initiator should or could
> get a range of ISIDs for their exclusive use.  This will be operating
> system specific and vendor defined.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

> -----Original Message-----
> From: Martin, Nick [mailto:[email-masked]]
> Sent: Wednesday, September 05, 2001 5:50 PM
> To: KRUEGER,MARJORIE (HP-Roseville,ex1); [email-masked]
> Subject: RE: iSCSI: login issue - partial consensus call
>
>
> Marj,
>
> You mention vendors not knowing how to play right.
> The problem is that iSCSI does not and will not specify how two HBAs
> from different vendors installed in the same Initiator should or could
> get a range of ISIDs for their exclusive use.  This will be operating
> system specific and vendor defined.  It is uncertain that the same tool
> or repository would be used by all HBA vendors in any environment.
> Given this, accidental overlap in ISID space is not unlikely.
>
> Given that there is no one way to play right, we must make sure that
> everyone can at least play nice.
>
> My expectation is that sessions are infrequently established and long
> lived.  ISIDs may be re-used at will by their current owners.  When no
> "already owned" ISIDs are available, or an attempt to re-use an "already
> owned" ISID failed, and HBA would need to a) "probe" for a new available
> ISID or b) fail the request to establish the session.  Session recovery
> should not be attempted unless a session is known to have failed.
>
> If tools are available, and the administrator has used them correctly,
> then HBAs will not collide in ISID space.  If the tools are not
> available or were not used correctly, I would hope the second HBA can
> still attempt to come up without impacting the sessions established by
> the first.
>
> Again, I state my support for a login with existing ISID harmlessly
> fails (the Target state does not change) unless a session recovery
> indicator is set.  Also if a session recovery indicator is set, and the
> ISID is not in use (by this Initiator at this Target), the login also
> fails.
>
> Thanks,
> Nick
> -----Original Message-----
> From: KRUEGER,MARJORIE (HP-Roseville,ex1)
> [mailto:[email-masked]]
> Sent: Friday, August 31, 2001 12:09 PM
> To: Martin, Nick; [email-masked]
> Subject: RE: iSCSI: login issue - partial consensus call
>
>
> > 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.
>
> The intent of the presentation on SCSI/iSCSI modeling, and the text in
> the
> draft, is to illustrate how this example is not a recommended
> implementation
> choice due to the probability of violating the SCSI/iSCSI
> rules pointed
> out.
> If the "independant agents" had partitioned the ISID space,
> there would
> be
> no collision on login and no time wasted.  Your illustrated
> implementation
> could spend significant time "trying" ISID's in use by the "other
> agents".
>
> However, I'm starting to have more sympathy with Julian's concerns due
> to
> the apparent risks of different vendors' initiator implementations not
> following the rules.
>
> I just imagined having vendor A's HBA installed and happily servicing
> applications, installing vendor B's "plug-n-play" implementation, and
> having
> all A's sessions aborted cause B doesn't know how to play right :-(
>
> Marj
>

---

From: Michael Schoberg <[email-masked]>
Date: Thu, 6 Sep 2001 11:04:21 -0500

Sorry this isn't a consensus message, but I just feel like the proposals
aren't getting us to the simplest solution.

Why put a square peg through a round hole?  A lot of things in this spec let
the client (initiator) dictate too much to the server (target).  Why?  If we
can't assume all initiators are aware of each other, why put things in the
protocol that can allow them to step on each other?  The target knows all
CID's, ISID's, TSID's, and everything else associated with the initiators
it's linked to, let it do the work of setting ID's.

CID - unique ID for this connection within the session.

The initiator doesn't need to specify this.  It only needs to set a flag
saying it wants to form a new connection for this session-ID.  Let the
target decide what the CID should be and send it back up to the initiator.
Letting the initiator decide this simply adds more checks to the target to
ensure that the initiator isn't trying to establish a connection-ID that
already exists.  Keep it simple.

ISID - initiator-defined session-identifier

Since initiators don't know about other initiators connected to this target,
this has the potential of causing problems.  Eliminate it.  The initiator
should simply state it's intentions of establishing a new session or adding
a connection to an existing session (via binary flags).  Recovery can be a
special case of the latter.  When the session or connection is established,
the target can return the ID's that make it unique the IC_T Nexus.  Those
ID's can be used to form new connections or recover from dropped
connections.

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Thu, 6 Sep 2001 14:38:17 -0700

I'm mystified as to why it's such an issue that an iSCSI HBA will have to
have a configuration interface, supplied by the manufacturer, in order to be
installed.  This is pretty much a MUST.  That is true of all "things that
need IP addresses, etc" assigned.  Yes, your product can try to select
defaults that may work (DHCP, etc) but there is no way they will work in all
environments.  So why do some seem to feel they should be able to create
iSCSI HBAs that require no configuration?  And if they require some
configuration, two items that should be configurable are iSCSI node name and
ISID range (in addition to IP address, netmask, gateway, DNS host, etc.
etc.).  What am I missing here?

It would be nice if this information could come from OS calls and someday it
might.  Meantime vendors supply config interfaces.  How can IP address(es)
come from the OS?  The iSCSI HBA needs the admin to assign a new one, not
use one the OS has assigned for other network interfaces.

And back on the topic of login behavior, I would submit that in order to
mandate Option B in the protocol, you need to refute the logic summarized so
elloquently by Jim in
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg06369.html

If you can't, option A seems the clear choice to me.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: [email-masked] 

> Sent: Thursday, September 06, 2001 1:33 PM
> To: [email-masked]
> Santosh,
> If an iSCSI HBA driver is going to live within the SCSI subsystems in
> today's operating systems, it will be told almost nothing 
> about the host
> through those interfaces.  When the driver initializes, it is 
> likely to
> be told only the PCI addresses of its adapter(s).  It is provided
> interfaces only to expose its SCSI request, ioctl request, 
> and hardware
> interrupt service routines.  It will not get the host name, or an IP
> address via interfaces in the SCSI subsystem.  Interfaces to collect
> information such as IP address, and host name which are available to
> network drivers, are not available to many storage drivers.  These and
> anything else needed will have to be collected from other interfaces.
> Some OS environments will provide a way for the SCSI driver 
> to initiate
> queries for this information, some will allow static 
> pre-configuration,
> others will need to wait for something to poke the information in
> through custom ioctl interfaces, or retrieve or construct 
> what is needed
> from non-volatile storage on the HBA card.  
> 
> This is partly a chicken and egg problem.  The host name for 
> example is
> normally retrieved from the system disk which can not be read 
> until the
> storage driver has completed its initialization.  If the boot storage
> controller could ask the OS for the host name, it would not get a good
> answer.
> 
> Operating systems will eventually comprehend the need for driver APIs
> for iSCSI which blend network and storage requirements, but initial
> implementations will be entirely supplied by the HBA or driver vendor.
> 
> IMHO, if a driver can initialize (bootstrap) without information from
> other sources, you make life much easier for the driver writers,
> testers, and users.  If all iSCSI drivers operating within 
> the same host
> need to agree on something which is not available through a 
> pre-existing
> interface, there will be problems.  If the administrator has 
> to manually
> set the same InitiatorName (and/or AccessID) for each iSCSI 
> driver, that
> is one thing.  If he has to manually set non-overlapping 
> ranges of ISIDs
> for each driver instance that will be more error prone.
> 
> The suggestion by Michael Schoberg to eliminate initiator 
> assigned ISID,
> and only use TSID which is already guaranteed to be unique makes sense
> to me.  
> 
> As Michael noted, we are a bit off of the consensus topic.
> 
> Thanks,
> Nick
> From: Santosh Rao [mailto:[email-masked]]
> Sent: Thursday, September 06, 2001 1:57 PM
> To: [email-masked]
> Subject: Re: iSCSI: login issue - partial consensus call
> 
> 
> "Martin, Nick" wrote:
> 
> In the above scenario, if the HBAs do not have an interface 
> to receive a
> range of ISIDs from the OS iscsi driver, then, they must also lack an
> interface to be handed down an iscsi initiator node name from the
> OS driver. Without using a common iscsi initiator node name, the ISID
> issue
> does not arise for multiple HBAs. [since each would be using its own
> iscsi
> name].
> 
> OTOH, if the HBAs have an interface to be handed down an 
> iscsi initiator
> node name from the OS driver, there's no reason for them to 
> not provide
> an
> interface to be handed down an ISID or a range of ISIDs for their use.
> 
> I am in favor of option (A) since it is the simplest and a 
> well designed
> HBA should be providing interfaces for the OS driver to assign the HBA
> an
> iscsi initiator node name as well as a range of ISIDs, thus, rendering
> Nick's scenario unlikely.
> 
> >
> If the tools were not available, how does the 2nd HBA get assigned the
> same
> iscsi initiator node name as the first ? The ISID issue is only
> applicable
> if both HBAs are sharing the same iscsi initiator node name.
> 
> I would like to understand the rationale behind an HBA interface
> allowing
> an initiator node name to be assigned, but not an ISID or a range of
> ISIDs
> (?).
> 
> 
> Regards,
> Santosh
> 
>

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Thu, 6 Sep 2001 19:51:06 -0400

We're not calling concensus on Mike's suggestion.  Even if Mike's suggestion
is implementable, the concensus question remains Option A or B?   If you
wish to discuss Mike's suggestion, please start another thread.  This one's
getting lost...

Marj 

> From: Sandeep Joshi [mailto:[email-masked]]
> Sent: Thursday, September 06, 2001 4:15 PM
> To: [email-masked]
> If we can step back a bit on this consensus call, I do
> agree with Nick on Mike's suggestion.  
> 
> http://www.pdl.cmu.edu/mailinglists/ips/mail/msg06373.html
> 
> -Sandeep
> 
> "Martin, Nick" wrote:
> >

---

From: [email-masked]
Date: Fri, 7 Sep 2001 09:56:52 -0400

Marj,

> wish to discuss Mike's suggestion, please start another thread.  This
one's

Already did that ... but this ISID issue needs to get resolved as part of
the Option A or B question because removing the ISID would remove Nick's
scenarios in which inadvertent reuse of ISIDs across adapters/interfaces
causes problems.  If that reuse can't happen, then Option A makes a lot more
sense, because the presence of a non-zero TSID on login can *only* refer
to a previously existing session.

Thanks,
--David

---

From: "John Hufferd" <[email-masked]>
Date: Fri, 7 Sep 2001 09:42:54 -0700

I would hand these out one after the other first Miniport gets ISID of 1,
next 2, etc.

Now I know you could have said the above, so I probably I did not interpret
your statement correctly.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: [email-masked]

"Eddy Quicksall" <[email-masked]>@ece.cmu.edu on 09/07/2001
06:51:06 AM

Please respond to <[email-masked]>

To:   John Hufferd/San Jose/IBM@IBMUS, "Sandeep Joshi"
      <[email-masked]>
cc:   <[email-masked]>
Subject:  RE: iSCSI: login issue - partial consensus call

John,

We really should do this so a driver can be written for existing OS's. How
would you hand out ISIDs when a Miniport is being loaded?

Eddy

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Thursday, September 06, 2001 3:21 PM
To: Sandeep Joshi
Cc: [email-masked]
Subject: Re: iSCSI: login issue - partial consensus call

I understand you point, however, the discussion we had on this, talked
about each HBA needing to have an install process that is OS specific.  It
was suppose to be an OS specific install or startup process that handed out
the ISIDs (or ISID ranges).

I think your point is that you wish that there was no reason to interact
with the OS, in order to get installed.  I do not think that is a good
assumption.

It is the OS that needs to let the HBA know what the iSCSI Initiator Node
Name is, so that the HBA can configure to use it.  It might as well hand
out the ISIDs at the same time.

You are suggesting that making the ID of the iSCSI HBA only a HW item.
This is not where we came down previously.  You want to make your job of
interfacing with the OS, simpler, and put more burden on the administrator.
This was the mistake we made with FC and I would not like to see that
repeated here.  You say that there needs to be Jumpers or switches, well
this is up to your adapter.  We use to do that kind of stuff before the
Plug and Play started working with the OS.  We need to work with the OS in
a similar manor.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: [email-masked]

Sandeep Joshi <[email-masked]>@research.bell-labs.com on
09/06/2001 11:44:00 AM

Sent by:  [email-masked]

To:   John Hufferd/San Jose/IBM@IBMUS
cc:   [email-masked]
Subject:  Re: iSCSI: login issue - partial consensus call

John,

Is this what you are referring to ? (Sec 1.3 of Naming & Discovery)

> b) The ISID name space of the iSCSI Initiator should be partitioned
>       among the intiator portal groups.

How do you perceive this will be achieved in practice ?

This can turn out to be an nightmare for HBA vendors.
IRQ settings, jumpers, or setup programs which run at boot
instantly come to mind.

Ideally, ISIDs should work as SCAM works but that would involve
adding a mid-layer to OSes, to distribute that ISID name space.
Modifying OSes in the field is tough, as we all know.

I realize the standard wont mandate such configuration items
but I'd rather we not add rules which would force such
configuration tweaks to become necessary.

We should reconsider the above rule and its consequence on
the login issue Nick brought up.

Regards,
-Sandeep

John Hufferd wrote:
>
> By the way, the OS is also suppose to have a way to hand out (partition
up)
> ISIDs to the various iSCSI Initiator functions, whether they are Software
> or Hardware.
>
> So, even though,  I was initially swayed by Nick's Arguments -- we
require
> the OS to partition up the ISID space and hand out specific ISIDs or
ranges
> of ISIDs (in some manor) to the iSCSI Initiator functions (regardless of
> whether they are in Software or Hardware) -- I do not now see, if the
> implementation is as specified in our spec., how there is a conflict in
> ISID.
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Home Office (408) 997-6136
> Internet address: [email-masked]

---

From: "John Hufferd" <[email-masked]>
Date: Fri, 7 Sep 2001 12:30:36 -0700

I am not now advocating the TSID centric SSID.  I in fact have my doubts
that any such change is worth the effort.  (Last minute changes to any
architecture/design is always fraught with potential unseen problems).
Especially since Jim Hafner, laid out an approach for getting the ISID
assigned.  However, independent of that, I think a fair hearing should be
held.

OK, OK,  now for my cut at the TSID remembering on a re-login.  I think the
issue is the thought that the iSCSI Initiator would want to re-establish
the same session or at least the same Nexus with the Target.  I also think
the point is that with the current design, the initiator would be able to
perhaps save the ISID, in some way, that it used last.  If it is the Target
that creates the SSID, and thereby fills in the ISID, at the end of the
Logon, the Initiator could save the generated (by Target ISID) as easily as
it could save one that it created.  So I do not think we added either any
problem here or solved anything relative to the reestablishment of a Nexus.

One thing we must remember is that we also have all SW iSCSI Initiator
nodes, so we already must support the capability to have dynamically
established ISIDs.

.
.
.
John L. Hufferd

10:42:49 AM

To:   Jim Hafner/Almaden/IBM@IBMUS, <[email-masked]>
cc:
Subject:  RE: iSCSI: login issue - partial consensus call

Jim,

Thanks. You're right about the more complex naming structure.

The more I think about this ... the more I think the TSID should be what is
used.

Part of the problem with the ISID is: How are you going to have a central
layer in OS's that already exist but also fit into SCSI for those systems?
That is why I thru up the thought of another naming convention.

The only problem with the TSID that I see now is what Millikarjun pointed
out ... if you wanted to reset after a crash, how would you figure out the
TSID? If no one can present a solution to that, I'll get off my band wagon.

Eddy

-----Original Message-----
From: Jim Hafner [mailto:[email-masked]]
Sent: Friday, September 07, 2001 12:09 PM
To: [email-masked]; [email-masked]
Subject: RE: iSCSI: login issue - partial consensus call

Eddy,

I think one way to view your proposal (and one which I more or less dropped
sometime ago, but may want to resurrect) is that you're assigning the
Initiator Name to the SCSI Initiator Port and the Host Name to the SCSI
Device.  You've effectively created a two-level naming scheme.

You propose then a Text keys=HostName and InitiatorName and both of these
have to get sent during login.

Rather than turning the cart over completely, let's take a different tact
for this.

Let's have the iSCSI Initiator Name name the host (as we've had it so far).
Let's allow for an 'extension' on this name that further qualifies a
subcomponent.  So, if my InitiatorName="iqn.2001-08.com.jlh", then I have
have statically assigned names like "iqn.2001-08.com.jlh:port1", etc. Each
of these new names would name a SCSI Initiator Port and within that name
space we'd have uniqueness of ISIDs.
Now, I can get this information over the wire at login with either
   initiatorname=iqn.2001-08.com.jlh
   portext=port1
(and use initiatorname for authentication)
OR
   initiatorname=iqn.2001-08.com.jlh:port1
AND make the presumption that everything before the : in the initiator name
is used for authentication, the rest is ignored.

Note that the 'port1' extension could easily be the portal group tag.

Note also, that the first of these is equivalent to your proposal, just
with keys reversed.  However, your proposal would require two levels of
world wide uniqueness, since both the hostname and the initiatorname would
have to be unique. (Unless the initiator name was assigned to adapters from
the outside in exactly the same manner as we need to assign ISIDs today!)

In short, the effect is exactly the same as you propose, either by adding a
different key explicitly or implicitly.

I abandoned this approach for two reasons.  First, it added more complexity
to the basic protocol (more keys or more assumptions). Second, the "port1"
extension is just another name 'self-assigned' by the initiator (through
some undefined mechanism) and I didn't see any functional difference
between assignment of this extension and assignment of ISIDs!  The ISID was
already an 'extension' to the initiatorname and already in the login
request.  What functional gain did we get by adding another field where we
put another 'piece' of a name?

Jim Hafner

"Eddy Quicksall" <[email-masked]> on 09/07/2001 06:33:10 am

To:   Jim Hafner/Almaden/IBM@IBMUS, <[email-masked]>
cc:
Subject:  RE: iSCSI: login issue - partial consensus call

Jim,

Thanks, this helps a lot.

The problem I had was that David Black said:

  "the iSCSI Initiator Name is supposed to refer to the
   host into which the HBAs are plugged"

So I was trying to rationalize that. The problem I have with this is that
it
will be difficult to get all HBAs and OS's to agree on how this
InitiatorName is going to become known to the HBAs and how the ISIDs are
going to be distributed to the HBAs. Especially when the best place for a
SCSI HBA in the windows world is as a Miniport.

So, I was thinking that the definition of InitiatorName should allow this.
I
think your explanation below does allow this. I think my original message
way down below fits your definition.

So, I attempted to suggest a definition of InitiatorName that would allow
both what you have said and what David said. When I said "unique", I was a
bit vague. What I meant was that the host could have several InitiatorNames
and each InitiatorName would be responsible for his creation of unique
ISID's.

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.

Someone mentioned an issue with authentication ... that process should not
require all HBA names to be known. Two things here:

  1) if several HBAs are being shared by a common driver, the driver is
well
aware of the HBA manufacturer (it is probably produced by the HBA
manufacturer) and the driver can be the InitiatorName (and hence distribute
ISIDs to its HBAs).
  2) but that does not fully cover the authentication point. i.e., that the
OS should be the apex for authentication. For that, we could have a
HostName. If an HBA does not want to play in that arena (because it is on a
private network), it could give a NULL for the HostName.

Eddy

-----Original Message-----
From: Jim Hafner [mailto:[email-masked]]
Sent: Thursday, September 06, 2001 4:55 PM
To: [email-masked]; [email-masked]
Subject: RE: iSCSI: login issue - partial consensus call

Eddy,

I'll try to take a crack at this question.

The problem is that the word "initiator" is being overused in these
discussions (same for "target").  I personally try to make a distinction in
every case, even if I sound pendantic.

In almost all cases in the iSCSI spec (and I think rev-08 will make this
explicit), the word 'initiator' means iSCSI initiator (an iSCSI Node doing
client stuff) unless otherwise qualified.  The iSCSI Initiator has exactly
one iSCSI Name.  An OS may have one such iSCSI Initiator in it, or it may
have several (depends on how you want to use them, but access rights etc
are supposed to be bound to the name, so fewer nodes in an OS means fewer
names means less configuration and more consistent views of storage within
the host).   An iSCSI Initiator can have multiple network interfaces,
lumped into groups (portal groups) with the property that within each
portal group, a cross network interface multiple connection session can be
built.  For example, I could have two iSCSI HBAs, each with dual ethernet
ports (and possibly different addresses for each port).  Ideally, this is
one iSCS Initiator, with two portal groups.

The other context of 'initiator' is "SCSI Initiator" and that further
qualifies to "SCSI Initiator Port" and 'SCSI initiator device'.  In our
case, the SCSI initiator device is 'attached' to the iSCSI Initiator (node)
and there is only one such attachment.  The SCSI Initiator ports are (as
defined now) the initiator end points of sessions (are dynamically
created).

I hope that much is clear. I've annotated your questions/quotes below with
my interpretation of which context the word initiator is implied.

Jim Hafner

"Eddy Quicksall" <[email-masked]>@ece.cmu.edu on 09/06/2001
09:50:02 am

To:   <[email-masked]>, <[email-masked]>
cc:
Subject:  RE: iSCSI: login issue - partial consensus call

David,

Now, I'm really confused...

I just read through the spec and I don't see where it mentions the
"Initiator" as you have presented it below. Can you please give me a
reference?

Section 1.1 appears to define "initiator" as:

  Clients of a SCSI interface are called "initiators".
<JLH> iSCSI Initiator" </JLH>

  Initiators are one endpoint of a SCSI transport.
<JLH> I think this is "iSCSI Initiator"; however, it is not unrelated to
the binding of one iSCSI Initiator to one SCSI Initiator Device, so you can
probably read both of these terms here.
</JLH>

Section 1.2.1 says:

   The group of TCP connections that link an initiator
   with a target, form a session (loosely equivalent to a SCSI I-T
   nexus).
 <JLH> iSCSI Initiator and iSCSI Target; it's the session which is loosely
equivalent to an I_T nexus.
 </JLH>

That does not seem to be consistent with your definition.

In parallel SCSI, you can have two different initiators
<JLH>
SCSI Initiator Port
</JLH> talking to the same
target
<JLH>
SCSI Target Port
</JLH>
 with both initiators on the same host
<JLH>
SCSI Initiator Device (or perhaps even finer than that)
</JLH>
... your use of Initiator
<JLH> to interpret David, I think this was iSCSI Initiator Node
</JLH>
does not seem to be consistent that that because you would allow only one
Initiator (the host).

Also, if the InitiatorName is the name of the host, how does an independent
HBA find out the name?

I would like to propose that "Initiator" refers to that end point which is
maintaining unique ISID's. I believe this definition would be consistent
with all that is in the spec.
<JLH>
I'm not clear what you mean with this definition.  "unique ISIDs" with
respect to a particular target or globally unique?  The later is not a
requirement.  The former is a requirement.  However, "maintaining" is
ambiguous.  If an iSCSI Initiator Node partitions its ISID space among its
portal groups (think HBAs here as is being discussed), then each portal
group is maintaining its portion of the ISID space according to the
uniqueness rules, but it's also true that by the simple act of
partitioning, the iSCSI Initiator Node is doing the same thing.  So who is
the "maintainer" in your case, the node or the portal group?
</JLH>

Eddy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, September 06, 2001 11:42 AM
To: [email-masked]; [email-masked]
Subject: RE: iSCSI: login issue - partial consensus call

Nope, the iSCSI Initiator Name is supposed to refer to the
host into which the HBAs are plugged (or, more precisely,
the OS instance using the HBAs for systems that support multiple
OS instances).  If we were to change the naming approach to
associate Initiator identities with network interfaces, this
particular issue gets easier, but we'd have to take another
hard look at why multiple sessions are allowed between the
same Initiator and Target (ditto multiple connections per
session).

--David

> From: Eddy Quicksall [mailto:[email-masked]]
> Sent: Thursday, September 06, 2001 10:57 AM
> To: [email-masked]; [email-masked]
> But wouldn't the two different vendors you mention below have
> different
> iSCSI Initiator Names? Remember, the Initiator is not the
> host, it is the
> HBA in this case.
>
> If two different HBA's are going to play together then a
> common driver would
> be used and the driver would provide the iSCSI Initiator
> Name. Then, the
> ISID would be properly maintained by the driver.
>
> Think of the Initiator Name as the owner of the ISID's for that name.
>
> Eddy
>

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 8 Sep 2001 09:53:15 +0300

The OS name (InitiatorName) is meant for the OS.
If you want to have one OS handle several sessions with a target you need
another element controllable by the host
to distinguish a session from another (i.e. the target should not be the
one to reassign it).  This is needed for the "long lived" things like
reservations that live beyond a session and have to be reassigned to their
rightful owners.

That was the reason we made-up the sessionID from two parts (and not a long
one assigned by one part).

For the CID the assigning entity was chosen arbitrarily (yes it could have
been the target but we needed him to check anyhow for a restart).

As for how to handle the a "bad ISID" I think that this issue has been
discussed far too long and very eloquent (i.e., convincing but not
necessarily right).  I have stated my position several times here and I am
not going to repeat it.

Julo

"Eddy Quicksall" <[email-masked]> on 07-09-2001 00:36:03

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  RE: iSCSI: login issue - partial consensus call

Julian,

There seems to be a lot of helter/scelter discussion in this thread. It
seems like the general problem is the ISID and it seems that the reason for
that is because the InitiiatorName has been assigned to the host.

I would like to propose the following but I think everyone is too engrossed
in solving a hard problem instead of making a hard problem easy. Or, maybe
I
just don't have enough background and I would just clutter the reflector
with stupid ideas.

Can you comment to me on this idea ... you have probably already gone
through it?

- make the InitiatorName be the name of the entity that maintains unique
ISID's. That could be an HBA or a driver controlling several NIC's.

- make a new name called the HostName that can be used for authentication.
The HostName could be optional because some special case HBA's may only be
used on closed connections and will not need authentication.

- to reset a session use the TSID instead of the ISID (because the target
can supply unique TSID's to everyone (may need to expand the TSID to 32
bits)) and use a bit in the login to say you are resetting.

BTW, I don't like the idea of making every run-time target "debug"
someone's
code ... that should be up to the host bashers.

Eddy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, August 31, 2001 12:24 AM
To: [email-masked]
Subject: iSCSI: login issue - partial consensus call

A review of this long running thread.  We started out with
Mallikarjun's three options:

       A) Should iSCSI let it happen by default as stated above (i.e.
          same ISID, TSID=0 always wipes out the pre-existing session
          on target, since we are mandating it to be used only when
          initiator sees a session failure)?
       B) Should iSCSI mandate making this intended cleanup explicit
          by setting a bit (Say C-bit, for Clear) in the Login Command
          PDU to prevent an accidental session cleanup with a buggy
          initiator code?
       C) Should iSCSI merely state that targets must ascertain
          the connection state(s) whenever a new session creation
          attempt is made with a known ISID and TSID=0?  (sort of
          defeats the intention of the initiator wanting quicker
          session recovery since the Login command PDU would have
          to idle till target ascertains the connection state(s)).

Based on my review of the emails, here's what I think the state
of the discussion is:

(1) I see no support for Option C.  The remaining options are A, B, and
     Julian's version of B in which the X bit is reused as the C bit.

(2) I see strong objections to the reuse of the X bit that Julian
     proposed, and no interest in it from anyone other than Julian.
     The objections are that the X bit is already heavily involved
     in error recovery and adding more semantics to it is an
invitation
     to trouble. Therefore, I believe the rough consensus of the IPS
     WG is that the X bit is not to be reused in this fashion.

(3) I believe the rough consensus is that the situation being analyzed
     here can occur as a consequence of an initiator reboot (i.e.,
     if the reboot is fast with respect to the target's timeout-based
     session cleanup).

The consensus calls in (2) and (3) are over Julian Satran's proposal/
comments/objection.  Anyone else who objects to these should post to
the list.

This leaves options A and B as originally stated.  Most people seem
to be in favor of option A - the two exceptions I noticed were
Julian and Venkat.  Julian's objection can be summarized with a
couple of quotes:

> Option A is prone to "wild closing of sessions"
> Option A is clearly unacceptable as an initiator may do harm.

The wild closing of sessions seems to be based on a different
iSCSI interface with the same Initiator name using the same
ISID.  This is a definite risk as it's an area in which iSCSI
differs from Fibre Channel.  FC identifies sessions via hardware
identities which tend to be static and unique, and set by the
hardware vendor.  The iSCSI ISID is a dynamically managed
entity, and bugs in managing it across multiple interfaces
(which may involve hardware and software from multiple
vendors) will cause this session closing problem, whereas for
it to happen in FC, the hardware identity has to be duplicated.

FWIW, I do know of an FC system that rejects duplicate logins
under some circumstances rather than implicitly destroying
the existing session, although I don't believe that behavior
can be overridden via inband means as is proposed here.

OTOH, a different OS should have different iSCSI Initiator Name,
and denial of service attacks should be foiled by proper use of
authentication.  I also tend to agree with the architectural
point of view that an initiator is in charge of its own sessions.
So, I think Julian has a point here, although some of the things
he's posted are overstated.

This is also Venkat's concern - unintentional reuse of an ISID
by the same Initiator:

> 2. There is some value in protecting an accidental use of an
> existing ISID by a second client (ISID=<existing>, TSID=0).
> This can be done with a Reject of the login attempt,

In contrast to some of the responses to Venkat, I interpret
"client" to mean another iSCSI port on the same Initiator, and
then his concern matches Julian's.  Venkat seems to think that
there's a useful distinction between boot scenarios in which
teardown of existing sessions is needed and boot scenarios
in which it's not needed  - I have no idea how to figure that
out in practice, and suspect that Marj is right when she says
that the C bit will be set all the time.  I agree that the
C bit is always set in a session recovery scenario because
the intent is to blow away the existing session.

So, I'm not ready to call consensus on the A vs. B. issue.
In hopes of making further progress, I would ask the
proponents of B (Venkat, Julian, and anyone else who thinks
this is valuable - I assume Julian prefers B to A, even if
the WG does not like using the X bit for B) to post short
answers to the following questions:

     Under what circumstances would an Initiator not set the
     C bit for option B?  What information would the Initiator use
     to decide not to set the C bit?

I apologize if this was in some of the emails and I missed
it - there were a lot of them.

Thanks,
--David

---

From: "Martin, Nick" <[email-masked]>
Date: Mon, 10 Sep 2001 15:35:27 -0500

Jim,

Although I am not an expert in Microsoft drivers, I have checked with an
expert and he confirms that "mini-port" storage drivers for NT4 did not have
the ability to "query" the registry using a "key".  If a command line for
this instance number of this driver is stored in the registry, it will be
passed to the driver as it initializes.  We have learned not to rely on
parameters passed from the registry in the driver command line.  There are a
number of conditions which can cause this information to be incorrect.  (As
an example two different controller models supported by the same driver will
each be treated as instance 0 and get the same command line.)

In my first hand Unix driver experience, I have found it rare for a driver
to be able to read a file.

If iSCSI is only to be used for secondary or auxiliary storage devices, then
utilities running from primary storage can supply the required parameters.
However, if iSCSI is to be used for primary storage (i.e. system disk or
root disk) then the iSCSI driver in the Initiator can not access parameters
stored on that disk to initialize itself before establishing a connection to
an iSCSI target.  Storage drivers must be able to initialize and operate in
the pre-boot and early-boot stages of system initialization before any disks
are available.  Dependence on parameters not available until the system disk
is mounted will prevent iSCSI from being usable as a system disk.

IMHO, indicating that these are easy problems with simple elegant solutions
seems misleading.

I am not saying these problems can not be solved.  Administrators can and
will configure whatever they are required to configure.  If they need it to
work, they won't give up until it does.  I just want to see that the number
of things that must be configured to use iSCSI effectively are kept to a
minimum.  I hope iSCSI can seem easier to administer than other storage
network technologies.

Thanks,
Nick

-----Original Message-----
From: Jim Hafner [mailto:[email-masked]]
Sent: Friday, September 07, 2001 11:23 AM
To: [email-masked]; [email-masked]
Subject: RE: iSCSI: login issue - partial consensus call

Eddy,

I have ideas on how this ought to be done, analogous to way that
InitiatorName would get assigned.

Take WinXX for example,  I'd have a well-defined registry key where the
miniports would look for their InitiatorName. The install of the first
iSCSI miniport driver would look for that key, not find it and then
instantiate whatever name is provided by the software installer.  After
that, any other driver installation (hopefully all driver installers would
use the same key) would see that value and accept it.  If not, then they
could use another vendor-key which would render them as being a 'separate
iSCSI Node' (and the conflict issues go away).

In a similar way, the registry could hold ranges of ISIDs for each driver
that installed.  A driver on installation would claim some range of ISID's
not already claimed by other drivers.  If a driver claimed too many, then
the next install might fail or trigger a management interface to reassign.
If a driver didn't play by these rules (either because it didn't want to or
was broken) then the customer probably get a new vendor!

Right now, miniport drivers already get some (typically vendor-specific)
information from the registry.  There is no reason to believe WE can't
cooperate in determining well-known keys for this purpose.

I suggested in a private e-mail with David Black that we could make this
ISID partitioning assignment a bit easier. For example, if we simply had in
the registry a 'counter' for each miniport as it loaded.  This counter
could map nicely to a Portal Group Tag.  Then we embed the portal group tag
in the ISID (in some field within the ISID).  Then you get explicit
partitioning of ISIDs without a direct management interface that can screw
up (David's concern).  The drivers effectively enumerate themselves (and
perhaps multiple portal groups for each driver, as needed) and the rest is
for free.  I think that drivers already enumerate themselves anyway, so
this shouldn't be a problem.

Similar things could happen for Unix and friends by just having a defined
/etc/initiatorname file and enumeration of the drivers in /dev/iscsi.

I didn't think this was such a big deal!

Jim Hafner

06:51:06 am

John,

Eddy

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Thursday, September 06, 2001 3:21 PM
To: Sandeep Joshi
Cc: [email-masked]
Subject: Re: iSCSI: login issue - partial consensus call

.
.
.
John L. Hufferd

John,

Regards,
-Sandeep

up)
require
ranges

---

From: "Jim Hafner" <[email-masked]>
Date: Mon, 10 Sep 2001 17:24:48 -0700

Nick,

I'm surprised by your comments.

I've had some (small) experience with both WinNT and Linux drivers (I've
hacked on both) and have used the registry to read configuration
information for WinNT and am currently reading a config file for a Linux
driver.   Even the network drivers in Unix have to read /etc/hostname and
other such files.  But YMMV.

As for the boot issue, this is orthogonal, in my opinion.  Boot will always
have to work differently (that's why there's a boot draft for iSCSI).  What
I identify myself as for a boot drive (InitiatorName, ISID) may not be what
I use for all other contexts.  I can use my boot identity to read enough of
the boot image to get my real identity and then reconnect to all my drives
(including, perhaps but not necessarily my boot drive) and off I go.  I
probably won't be able to connect to all my drives right up front anyway
(that's not even how any boot works, as far as I know).  Typically, boot
reads via BIOS just enough to get going on the first disk and then loads
the real drivers for each logical unit it finds.  The bus scan for the
"other logical units" is driven by the kernel (after it loads), not by
BIOS.

So, you're correct that for just boot I'll need a RAM/BIOS based
InitiatorName, but that need not be my "true" identity for access to all
drives after kernel boot.  But such a BIOS will also have to have a fair
chunk of network configuration information, as well as either a static
(RAM/BIOS) ipaddress for iSCSI boot disk or will have to have a lot of
"discovery" logic (e.g., SLP, iSNS, etc) to find the place that knows where
my boot disk is.  If I can configure that much, then I can configure an
InitiatorName of my true identiry as well (if needed).

Additionally, for boot, I only need on connection (this is not really
performance path, and I almost surely don't want the complexity of path
failover, etc), so I only need one ISID for that (might as well pick
ISID=zero).  Then I can always have my "on the fly" drivers use non-zero
ISID and there will be no collisions with the boot logic.

Jim Hafner

"Martin, Nick" <[email-masked]> on 09/10/2001 01:35:27 pm

To:   Jim Hafner/Almaden/IBM@IBMUS, "[email-masked]'" <[email-masked]>
cc:
Subject:  RE: iSCSI: login issue - partial consensus call

Jim,

Although I am not an expert in Microsoft drivers, I have checked with an
expert and he confirms that "mini-port" storage drivers for NT4 did not
have
the ability to "query" the registry using a "key".  If a command line for
this instance number of this driver is stored in the registry, it will be
passed to the driver as it initializes.  We have learned not to rely on
parameters passed from the registry in the driver command line.  There are
a
number of conditions which can cause this information to be incorrect.  (As
an example two different controller models supported by the same driver
will
each be treated as instance 0 and get the same command line.)

If iSCSI is only to be used for secondary or auxiliary storage devices,
then
utilities running from primary storage can supply the required parameters.
However, if iSCSI is to be used for primary storage (i.e. system disk or
root disk) then the iSCSI driver in the Initiator can not access parameters
stored on that disk to initialize itself before establishing a connection
to
an iSCSI target.  Storage drivers must be able to initialize and operate in
the pre-boot and early-boot stages of system initialization before any
disks
are available.  Dependence on parameters not available until the system
disk
is mounted will prevent iSCSI from being usable as a system disk.

Thanks,
Nick

-----Original Message-----
From: Jim Hafner [mailto:[email-masked]]
Sent: Friday, September 07, 2001 11:23 AM
To: [email-masked]; [email-masked]
Subject: RE: iSCSI: login issue - partial consensus call

Eddy,

Jim Hafner

John,

Eddy

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Thursday, September 06, 2001 3:21 PM
To: Sandeep Joshi
Cc: [email-masked]
Subject: Re: iSCSI: login issue - partial consensus call

.
.
.
John L. Hufferd

John,

Regards,
-Sandeep

up)
require
ranges

---

From: "Prasenjit Sarkar" <[email-masked]>
Date: Mon, 10 Sep 2001 20:55:34 -0700

Jim, Nick,

I think Jim is right that it is possible to read files/registry but Nick is
also right that there are
various OS and architecture-specific restrictions on when certain
operations are permitted.
My experience tells me that making a list of OSes and then OS-specific
mechanisms for
ISID partitioning is going to be non-trivial, though I would not prevent
anyone from venturing
into this :-).

Prasenjit

   Prasenjit Sarkar
   Research Staff Member
   IBM Almaden Research
   San Jose

                    Jim                                                                        
                    Hafner/Almaden       To:     "Martin, Nick" <[email-masked]>,      
                    /IBM@IBMUS            [email-masked]                                      
                    Sent by:             cc:                                                   
                    owner-ips@ece.       Subject:     RE: iSCSI: login issue - partial         
                    cmu.edu               consensus call                                       

                    09/10/2001                                                                 
                    05:24 PM                                                                   

Nick,

Jim Hafner

Jim,

Thanks,
Nick

-----Original Message-----
From: Jim Hafner [mailto:[email-masked]]
Sent: Friday, September 07, 2001 11:23 AM
To: [email-masked]; [email-masked]
Subject: RE: iSCSI: login issue - partial consensus call

Eddy,

Jim Hafner

John,

Eddy

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Thursday, September 06, 2001 3:21 PM
To: Sandeep Joshi
Cc: [email-masked]
Subject: Re: iSCSI: login issue - partial consensus call

.
.
.
John L. Hufferd

John,

Regards,
-Sandeep

up)
require
ranges

---

From: "Julian Satran" <[email-masked]>
Date: Tue, 11 Sep 2001 11:30:18 +0300

Nick,

Most operating systems and that includes W2K know how to partition a set of
resources to drivers (see plug-and-play) statically and a few of them have
quite elaborate mechanisms to allocate resources dynamically
(and that includes most of the Unix flavors). As ISIDs are handed out only
at login any for of partitioning can assume
host participation.  Jim's warning was to the implementers - and it should
read "do it from your first version".

And as I said earlier targets are more likely to be multi HBA and passing
over the allocation only complicates things.

Julo

"Martin, Nick" <[email-masked]>@ece.cmu.edu on 10-09-2001 23:35:27

Please respond to "Martin, Nick" <[email-masked]>

Jim,

Thanks,
Nick

-----Original Message-----
From: Jim Hafner [mailto:[email-masked]]
Sent: Friday, September 07, 2001 11:23 AM
To: [email-masked]; [email-masked]
Subject: RE: iSCSI: login issue - partial consensus call

Eddy,

Jim Hafner

John,

Eddy

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Thursday, September 06, 2001 3:21 PM
To: Sandeep Joshi
Cc: [email-masked]
Subject: Re: iSCSI: login issue - partial consensus call

.
.
.
John L. Hufferd

John,

Regards,
-Sandeep

up)
require
ranges