RE: iSCSI: login issue - partial consensus call

["Martin, Nick" <Nick.Martin@compaq.com>]

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: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Thursday, August 30, 2001 11:24 PM
To: ips@ece.cmu.edu
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

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