SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    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:55 2001
6315 messages in chronological order