RE: iSCSI: reusing ISID for recovery

["Mallikarjun C." <cbm@rose.hp.com>]

Julian,

I disagree that it is an optimization that most of us are
seeking, but more to the point...

I continue to prefer option A even after this proposal.  

Reasons?

o Attaching more semantics to X-bit is only more complexity.
  Only "plug command" and "reinstate connection" until now; 
  with this additionally, "lost my way" (if TSID = 0). 

o This is option B (overloading X-bit instead of a new C-bit), 
  which we all (I thought including you) agreed shouldn't be 
  adopted.

o I am unclear on the model you have in mind on authentication
  - going with any of these models.  I am further perplexed with
  this response you gave to Marjorie -

>When I say without authetication I meant only on option A.

  To quote my original email yet again, here is my phrasing:

  "at the end of the login process including any initiator authentication"

  I believe that's the only time a target must decide to invoke
  option A.

Regards.
--
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.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
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
>> >
>> >
>> >
>> >
>>
>>
>>
>
>
>
>
>