SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI: reusing ISID for recovery



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


Home

Last updated: Tue Sep 04 01:03:52 2001
6315 messages in chronological order