Subject: iSCSI: login issue - partial consensus call

From: [email-masked]
Date: Fri, 31 Aug 2001 00:24:17 -0400

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

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

---

From: "Julian Satran" <[email-masked]>
Date: Fri, 31 Aug 2001 08:53:40 +0300

The X bit sematic in login today is "restart the connection".
You may add to it "restart the session" and Marjorie was the only one
(mildly) objecting to it.
However I would like to point out that the C bit has no real value if not
checked as users are prone to set it always on.
If checking is out then A is good enough.

Julo

[email-masked]@ece.cmu.edu on 31-08-2001 07:24:17

Please respond to [email-masked]

Sent by:  [email-masked]

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

Thanks,
--David

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Fri, 31 Aug 2001 08:35:45 -0700

One clarification..

> then his concern matches Julian's. 

"Another port on the same initiator" by definition has a different ISID and
thus this problem is not possible.  Maybe you mean another iSCSI driver?

> Venkat seems to think that
> there's a useful distinction between boot scenarios in t which
> in which it's not needed

I haven't seen any examples where teardown of the dup session would not be
the desired behavior (or would be harmful).  That's the rationale I'd like
to hear.  If there isn't any conceivable use of the login reject
information, then perhaps it would satisfy Julian and others if we could
maintain the behavior of option A, but inform the initiator (via some sort
of reponse code) that an existing session had been aborted as a result of
this login?

Marj

---

From: [email-masked]
Date: Fri, 31 Aug 2001 11:44:06 -0400

> thus this problem is not possible.  Maybe you mean another iSCSI driver?

Looks like I should have capitalized Initiator, as I meant it in the sense
that iSCSI defines the term.  The potential scenario here is two different
iSCSI boards are part of the same iSCSI Initiator, and something goes wrong
in the ISID coordination that has to happen between them.  Two different
device drivers is one way to increase the ways to get this wrong (yes,
the ISIDs are supposed to be different, but they're set up dynamically
between the devices and their drivers, and software bugs happen).

Thanks,
--David

---

From: Venkat Rangan <[email-masked]>
Date: Fri, 31 Aug 2001 09:00:55 -0700

>	to decide not to set the C bit?

The only time an Initiator would set the C bit is when it knows
by its own state that the target needs to be cleaned, i.e., it did not
cleanly logout all sessions cleanly, using a normal shutdown. How this
state is preserved across reboots is implementation detail on the
Initiator.

In any case, this adds complexity on the initiator, for which there
seems to be only marginal benefit.

Venkat Rangan
Rhapsody Networks Inc.
http://www.rhapsodynetworks.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, August 30, 2001 9:24 PM
To: [email-masked]
Subject: iSCSI: login issue - partial consensus call

Thanks,
--David

---

From: Venkat Rangan <[email-masked]>
Date: Fri, 31 Aug 2001 08:47:27 -0700

David,

Benefits of Option B) appear to be small for the added complexity, so I also
am now convinced that Option A) is a better choice.

Venkat Rangan
Rhapsody Networks Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, August 30, 2001 9:24 PM
To: [email-masked]
Subject: iSCSI: login issue - partial consensus call

Thanks,
--David

---

From: "Martin, Nick" <[email-masked]>
Date: Fri, 31 Aug 2001 11:45:25 -0500

David,

I think we should give Initiators both 1) the capability to attempt a "new
login" which can do no harm, but will fail if a session with this ISID in
use, and 2) the capability to force an existing session to reset and
re-login.  I support the idea that the initiator should state its intention,
and if the action would not match the intention, no action is performed, and
an error code is returned.

Given both capabilities, I would always attempt the "new login" first.

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.  To clarify independent
agents, this refers to any iSCSI stack which may not be able to co-ordinate
ISIDs with others within the same Initiator.  These could include BIOS ROM,
iSCSI software stacks, and/or iSCSI acceleration hardware or firmware any of
which may be controlling one or more instances of similar, or dissimilar
shared or unshared network interfaces within one or more chassis can which
act as one iSCSI Initiator.  

I support B) without having a strong opinion about C bit versus X bit.

I still have questions about how long we expect it to take for a target to
detect a missing initiator and clean up an old session without being asked
to do so.  (If no-one forces a session to close, how long will it remain
"active" in the target after its initiator fails.)  Also I am unsure of the
proper steps the target should take in attempting to discover or verify a
missing initiator.  Will these be specified, or left to implementors?

Thanks,
Nick
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, August 30, 2001 11:24 PM
To: [email-masked]
Subject: iSCSI: login issue - partial consensus call

Thanks,
--David

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Fri, 31 Aug 2001 13:09:18 -0400

> 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