RE: iSCSI: reusing ISID for recovery

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

Marjorie, Jim, Mallikarjun, Deva & all

Let's attemp to close that optimization that is so dear to your hearts.
If we go for the following scheme (very close to B):

The initiator knows "that he lost his way" (in the initiator jungle tough)
and issues a Login + ISID + TSID=0 + X bit on (meaning
" I think I have an old session - please clean it up for me" and open a new
one) then the target may do one of the following:

- before going to the effort of authenticating the new initiator check if a
session exist (if he has the initiator name) or go to authentication if it
does not
- If he has a session then clean it and create a new one
- If he does not have a session - we have 3 options:
a)- tell him hid did not have an old session and drop him
b)- tell him he did not have an old session but nevertheless create a new
one
c)- create a new session and do not tell him

With option a we are close to the old option c but the initiator does not
have to find the old session he can do now safely a new login
With b & c  we are back at the old b.

Which one would you give your kingdom for ( and my peace!).

Julo

"Dev" <deva@stargateip.com>@ece.cmu.edu on 28-08-2001 01:44:15

Please respond to <deva@stargateip.com>

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


To:   "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" <marjorie_krueger@hp.com>,
      <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



All,

When a session is already running authenticated, a login request with the
same
ISID + initiator fails authentication. Will the session continue to run?
Or
if the target fails during parameter negotiation?

I guess, yes. i.e. target will not act on the existing session, until
the login completes successfully. Or are there exception to these?

Thanks

Deva
Platys Communications





> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Saturday, August 25, 2001 12:23 AM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: reusing ISID for recovery
>
>
>
> It may be another OS running on the same machine or CPU
> complex or it could
> be an attack.
> In any case if the initiator is up and fine he can as well do logout.
> It is a rare enough event for us not to try to optimize.
>
> The reboot is the only case in which the initiator can't
> logout and about
> which we care.
>
> And I would like to remind you all that we where on this
> exact thread more
> tan 3 months ago (other players).
> I just restated the rationale for an (apparent) newcomer.
>
> Julo
>
> "KRUEGER,MARJORIE (HP-Roseville,ex1)"
> <marjorie_krueger@hp.com>@ece.cmu.edu
> on 25-08-2001 03:51:43
>
> Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
>       <marjorie_krueger@hp.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: reusing ISID for recovery
>
>
>
> I don't see how Option A is prone to "wild closing of sessions".  The
> target
> is only looking for sessions with this particular initiator
> and closing
> them
> if the ISID matches.
>
> If an initiator doesn't have a valid TSID (login w/TSID=0),
> it means it has
> lost state entirely (reboot) or knows it wants to immediately reset a
> session (NIC failure).  How could there possibly be a case where the
> initiator has an active valid session with the same ISID, but
> just doesn't
> know about it??  Rejecting the login seems pointless, since
> obviously the
> initiator either has a bug or intends to quickly reset the session.
>
> The behavior chosen (Option C) will cause the initiator's
> recovery to be
> delayed while the target NOPs all the connections and waits
> for them to
> time
> out - this will only delay the initiators recovery
> unnecessarily.  I can't
> help but think this will cause long term problems for the protocol.
>
> Marjorie Krueger
> Networked Storage Architecture
> Networked Storage Solutions Org.
> Hewlett-Packard
> tel: +1 916 785 2656
> fax: +1 916 785 0391
> email: marjorie_krueger@hp.com
>
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Thursday, August 23, 2001 9:39 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> > - Change -
> > Login/Text...)
> >
> >
> >
> > Mallikarjun,
> >
> > On  your point 1 that is what is stated today in the draft.
> >
> > On your point 2 option C is the one we took in the draft, after some
> > debate.
> >
> > Option A is prone to "wild closing of sessions" and option B is also
> > relaying to much on the good behaviour of the
> > client. It also introduces a "feature" that complicates
> login/logout.
> >
> > Our postion on this is  that the initiator should logout the session
> > explicitly if it can (and in this case it can as the target
> > has ascertained
> > that the session is alive).
> >
> > I agree that you may want to update the stayte diagram to
> > reflect this.
> >
> > Julo
> >
> >
> > "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on
> 24-08-2001 01:46:40
> >
> > Please respond to cbm@rose.hp.com
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> >
> > To:   ips@ece.cmu.edu
> > cc:
> > Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> - Change -
> >       Login/Text...)
> >
> >
> >
> > Julian and all:
> >
> > This thread mirrors another discussion some of us are
> > having in a different forum.  Following (two bullets 1
> > & 2 below) is what I proposed there, attempting to address
> > two issues -
> >      a) how to recover sessions when target and the initiator
> >            have conflicting views of the same TCP connection(s)?
> >            (Initiator NIC fails, but there's no I/O activity,
> >            and the target doesn't see any connection failure.)
> >      b) More specifically, how to address the above problem
> >            when the initiator *does not want* to re-instate failed
> >            connections since it only implements the mandatory
> >            session recovery?
> >
> > This could add clarity or muddle things up here, though hopefully
> > the former...
> >
> > 1 If login is sent with the same ISID, same TSID, same CID
> and X-bit,
> >   then it means a failed connection is being re-instated (whether
> >   or not there are multiple connections in the session).  This login
> >   attempt must be done before the connection timeout
> (transition M1),
> >   or if this is the only connection in the session, also before the
> >   session timeout (transition N6) - to be counted as a connection
> >   reinstatement effort.
> >            o CmdSN counters (CmdSN, ExpCmdSN) are continued.
> > Initiator
> >              must do command plugging when there's a mismatch
> >              between its CmdSN and ExpCmdSN in the login response.
> >            o Since this is an implicit connection logout, all
> > the active
> >              tasks on the connection are either internally
> terminated,
> >              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
> >              TBD) for recovery.
> >
> > 2 If login is sent with the same ISID and TSID=0, the session (if it
> >   exists on the target) is being cleared and any active connections
> >   that the target sees must be immediately (at the end of the login
> >   process including any initiator authentication) transport reset.
> >   Initiator may attempt this only after it ascertains a
> > session failure
> >   on its end (ie. all connections entered RECOVERY_START).
> >            o CmdSN counters get reset.  Initiator has to perform the
> >              currently defined session recovery actions.
> >            o All active tasks of the session are internally
> > terminated.
> >
> >
> > Essentially, I was proposing extending the same notion of "implicit
> > logout" of a connection to the session level.  The options that I
> > see are -
> >
> >        A) Should iSCSI let it happen by default as stated above (ie.
> >           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)).
> >
> > I prefer A, or B.
> >
> > Going with A or B means that the description of transition N3
> > in the session state diagram would have to change to:
> >      Last LOGGED_IN connection had ceased to be LOGGED_IN,
> >         or a Login Command requesting clearing the session (also
> >         with C-bit set, if option B) was received by the target.
> >
> > The transition N7's description would have to be augmented as
> > well to:
> >         Session recovery attempt with an implicit logout,
> >         or connection reinstatement/new CID addition.
> >
> > Comments?
> > --
> > Mallikarjun
> >
> >
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions Organization
> > MS 5668   Hewlett-Packard, Roseville.
> > cbm@rose.hp.com
> >
> >
> > >Stephen,
> > >
> > >That can happen as the target may set-up completely new TCP
> > connections
> > >(the old sockets are still there and look OK).
> > >Untill the login is  progessing he assumes that this is
> just another
> > >open-session attempt. Then he checks the old session and the
> > session is
> > >dead (initiator has closed the connections).
> > >
> > >The target has to distinguish only between a session that is
> > alive (and
> > >reject the new one) and one that its dead in which case it
> > can clean-up.
> > >
> > >Julo
> > >
> > >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on
> 23-08-2001 22:50:56
> > >
> > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > >
> > >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> > >cc:
> > >Subject:  RE: iSCSI - Change - Login/Text commands with the
> > binary stage
> > co
> > >          de
> > >
> > >
> > >
> > >Julian,
> > >
> > >I don't understand your answer.  For the scenario given, I
> > would presume
> > >then that the target would reject the new session attempt,
> > as it sees the
> > >previous session still "alive".  What is there to tell the
> > target that
> > this
> > >is any different from when the Initiator is erroneously using the
> > >repetitive
> > >session id?
> > >
> > >Thanks,
> > >Stephen
> > >
> > >-----Original Message-----
> > >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > >Sent: Thursday, August 23, 2001 11:15 AM
> > >To: ips@ece.cmu.edu
> > >Subject: Re: iSCSI - Change - Login/Text commands with the
> > binary stage
> > >co de
> > >
> > >
> > >Stephen,
> > >
> > >1.If the initiator goes away for a while and reboots and
> there was no
> > >activity on the connections
> > >the target may see a session alive (I am not sure that it
> > has to appear on
> > >the state diagram but maybe).
> > >
> > >2.Again - I am not sure that the curent state diagram
> > includes death of
> > the
> > >initiator
> > >
> > >Julo
> > >
> > >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu
> > on 23-08-2001
> > >19:58:34
> > >
> > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > >
> > >Sent by:  owner-ips@ece.cmu.edu
> > >
> > >
> > >To:   ips@ece.cmu.edu
> > >cc:
> > >Subject:  Re: iSCSI - Change - Login/Text commands with the
> > binary stage
> > co
> > >      de
> > >
> > >
> > >
> > >Julian,
> > >
> > >1.3.6 ISID states that the target should check to see if the
> > old session
> > is
> > >still active when a duplicate session is detected.
> > >
> > >I have two questions, the second only if you answer in the
> > affirmative on
> > >the first ;^)
> > >
> > >1. Is there a properly executed sequence of events (i.e., no
> > coding error
> > >on
> > >the target side) where the session is not active, but the
> > target hadn't
> > >taken notice of it?  It appears this as a protocol-specified
> > means to work
> > >around a flaw in a target's implementation.  I interpret the
> > state diagram
> > >transitions as being atomic wrt other commands.  I.e., the
> > last logout
> > >would
> > >result in the various transitions of the connection/session
> > prior to the
> > >initiator starting the session up again.  And the target would have
> > >completed the transitions prior to handling a new session request.
> > >
> > >2. If you answered (1) in the affirmative, then the word
> > "Active" is not
> > >consistent with the 6.3 Session State Diagram.  Does this
> > mean the target
> > >got lost, due to transport failures of any sort, in its
> > transition from
> > >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the
> > old session if
> > >the session was in Q2 or Q4, presuming if it were in Q1,  it
> > would not
> > have
> > >been found as a duplicate.
> > >
> > >Stephen
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>