|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: reusing ISID for recoveryJulian, >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 Are you saying that authentication is not required when a login request with ISID + TSID= 0 + X bit is set? Or will it result in a valid session close when a forced access to the target is attempted by a hacker? What exactly if some hacker issues to the target with retry bit set and gains access? I thought authentication will protect the existing session from a 'me too' hacking identifications? Am I missing something here? >- 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 Does your proposal (i.e. with 'X' bit set) take care of the case , when the initiator reboots (probably after a crash) while a session is still active in the session? How is that taken care of? Thanks Deva Platys communications -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Monday, August 27, 2001 9:39 PM To: ips@ece.cmu.edu Subject: 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 |