RE: iSCSI: Need to Kill Session from Surviving Node

[Douglas Otis <dotis@sanlight.net>]

John,

It does bring up some interesting points.  If there is loss of ability to
process any further PDUs due to a loss of a single PDU due to a digest
error, there can be no further communication on that connection other than a
TCP graceful close with perhaps data sent past the point where a problem was
detected.  Rather than issuing a reject, a message indicating the closing of
the connection would be appropriate but it would be without acknowledgement.
There is a requirement in this case of always allowing multiple connections
for the case of recovery if a close is not possible.  There should be no
single connection limitation in this case or take-over is not possible.
Perhaps the minimum would be two connections and always a free connection
allocation.  There would seem to be a need for a clear definition of how
this recovery takes place to ensure sequential integrity.  There seems a
reluctance in specifying these details as it limits some architectural
freedom but these details are just as much a part of this protocol as are
the PDU structures.

Several have argued that it would be impractical to have this transport
attend to LUNs, the issue of reset is also interesting.  Presently there is
no convention for differentiating systems with or without administrative
authority to allow filtering such system wide commands.  It could be a
convention provided by the authority information stored within a
standardized database.  My vote would be to develop a schema for LDAP to
address this issue or decide if command filter is even practical.

Doug

> Wait a minute, I did not expect my Surviving Node question to somehow
> trigger the discussion of whether the Target Reset should be issued by
> iSCSI Initiators.   That is a completely different Pit.
>
> My question was, when the Storage Controller fails over to a surviving
> NODE, how do we tell the Initiator that is waiting peacefully for the
> TCP/IP connection to time-out.  To quickly give-up and let the initiator's
> SCSI layer, retry the operations, so that the iSCSI layer can start either
> sending the SCSI cmds to the Surviving Node, or starts a new Session with
> the Surviving Node.
>
> This has nothing to do with the Initiator issuing Target Resets.
>
>
>
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Internet address: hufferd@us.ibm.com
>
>
> "Somesh Gupta" <someshg@yahoo.com>@ece.cmu.edu on 03/14/2001 08:25:58 PM
>
> Please respond to <someshg@yahoo.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   <cbm@rose.hp.com>, <someshg@yahoo.com>
> cc:   <ips@ece.cmu.edu>
> Subject:  RE: iSCSI: Need to Kill Session from Surviving Node
>
>
>
> Mallikarjun,
>
> I am not disagreeing with the desire to do a graceful
> termination. However, when recovery states at the TCP
> level, and at the iSCSI level get intertwined with this,
> it is probably better to focus on a clean (possibly graceful)
> termination and a clean bringup.
>
> Somesh
>
> > -----Original Message-----
> > From: cbm@core.rose.hp.com [mailto:cbm@core.rose.hp.com]On Behalf Of
> > Mallikarjun C.
> > Sent: Wednesday, March 14, 2001 7:31 PM
> > To: someshg@yahoo.com
> > Cc: ips@ece.cmu.edu
> > Subject: RE: iSCSI: Need to Kill Session from Surviving Node
> >
> >
> > Somesh,
> >
> > Please refer to the following URL (and emails around that) for
> > a long discussion on this topic.  Both flavors of resets have value,
> > and I agree with Julian that iSCSI should support both.
> >
> > http://ips.pdl.cs.cmu.edu/mail/msg00740.html
> >
> > --
> > Mallikarjun
> >
> >
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions Organization
> > MS 5668 Hewlett-Packard, Roseville.
> > cbm@rose.hp.com
> >
> >
> > >Do you need both a "warm-reset" and a "cold-reset"?
> > >The "warm-reset" seems to be an over-optimization.
> > >
> > >Somesh
> > >
> > >> -----Original Message-----
> > >> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On
> Behalf Of
> > >> Mallikarjun C.
> > >> Sent: Wednesday, March 14, 2001 12:16 PM
> > >> To: ips@ece.cmu.edu
> > >> Subject: Re: iSCSI: Need to Kill Session from Surviving Node
> > >>
> > >>
> > >> >There is a related problem that I think we need to address, and
> > >> that is --
> > >> >the case where the Storage Controller is an Active-Active
> > Fail-Over unit
> > >> >with very little state shared between the Storage Controller
> > Nodes.  (I
> > >> >think a number of you folks have told me that you are
> planning such a
> > >> >design.)  This would mean that a specific initiator OS (WWUI)
> > would have
> > >> >separate sessions between the Nodes.  At fail-over, the
> > >> Take-Over Node will
> > >> >want to cause the Initiator, to Stop messing around with the
> > Failing node
> > >> >ASAP, and start using the existing session, or start a new
> > >> session with the
> > >> >Take_Over Node.  The Initiator, will normally just time-out the
> TCP/IP
> > >> >connection, and then turn the recovery over to the SCSI
> > Layer. Then, when
> > >> >SCSI retries, iSCSI will either use the Session to the
> > Surviving Node or
> > >> >Create a New Session to that Surviving Node.  The problem is,
> > that this
> > >> >will take a longer time then a system might want.
> > >> >
> > >> >So the question: is there a way for a surviving Target Node
> > to tell the
> > >> >Initiator to "Kill" the Session to the Failing Target Node?
> > >> >
> > >> >Comments?
> > >>
> > >> Assuming that the failing Node is still able to execute commands,
> > >> a cold target reset from the Initiator to the failing node
> > should "kill"
> > >> all the sessions to it.
> > >>
> > >> The answer to two hosts configured in a failover
> configuration sharing
> > >> a single Storage Controller Node is also the same.
> > >>
> > >> If it is active-active configuration, it appears to me that there's a
> > >> need to somehow prompt the Initiator to doing the reset on a
> > third party
> > >> (Async PDU?).
> > >>
> > >> This is a reason why we'd still need target reset in iSCSI.
> > >> --
> > >> Mallikarjun
> > >>
> > >>
> > >> Mallikarjun Chadalapaka
> > >> Networked Storage Architecture
> > >> Network Storage Solutions Organization
> > >> MS 5668   Hewlett-Packard, Roseville.
> > >> cbm@rose.hp.com
> > >>
> > >> >
> > >> >.
> > >> >.
> > >> >.
> > >> >John L. Hufferd
> > >> >Senior Technical Staff Member (STSM)
> > >> >IBM/SSG San Jose Ca
> > >> >(408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> > >> >Internet address: hufferd@us.ibm.com
> > >> >
> > >> >
> > >> >Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 03/14/2001 08:31:19 AM
> > >> >
> > >> >Sent by:  owner-ips@ece.cmu.edu
> > >> >
> > >> >
> > >> >To:   ips@ece.cmu.edu
> > >> >cc:
> > >> >Subject:  Re: iSCSI: Logout needs ISID
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >Mark,
> > >> >
> > >> >If you have only one connection you are supposed to use a
> > Login with the
> > >> >restart bit one - and achieve a similar effect as a
> > Login/Logout - i.e.
> > >> >keep the session alive.  Even this might be a problem for a
> > >> target that is
> > >> >so poor it has only one socket (even SNMP won't work there).
> > >> For this case
> > >> >the only way out is to drop the connection and hope the
> > target will hear
> > >> >you (it probably won't -:)). The comment is the draft is a memento
> for
> > >> >implementers to keep looking for new connections always (even
> > for a one
> > >> >connection target) but probably it does not come through clear
> enough.
> > >> >
> > >> >Regards,
> > >> >Julo
> > >> >
> > >> >Mark Bakke <mbakke@cisco.com> on 14/03/2001 18:17:14
> > >> >
> > >> >Please respond to Mark Bakke <mbakke@cisco.com>
> > >> >
> > >> >To:   Julian Satran/Haifa/IBM@IBMIL
> > >> >cc:   ips@ece.cmu.edu
> > >> >Subject:  Re: iSCSI: Logout needs ISID
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >Julian-
> > >> >
> > >> >A target that does not support multiple connections per session
> > >> >will return "Initiator SID Error" when the login attempt is made.
> > >> >In this case, there is no way to log in, so there's no way to
> > >> >log out the old connection.  The initiator would be stuck waiting
> > >> >until the target's side of the connection times out and goes
> > >> >away, which could be a very long time.
> > >> >
> > >> >There is an open question within the MIB team about whether anyone
> > >> >needs to be able to kill connections or sessions from SNMP; however,
> > >> >I don't think that anyone will want to use SNMP as part of error
> > >> >recovery.
> > >> >
> > >> >--
> > >> >Mark
> > >> >
> > >> >julian_satran@il.ibm.com wrote:
> > >> >>
> > >> >> Josh,
> > >> >>
> > >> >> No command, including logout, can be sent without a login.
> > >> >> The complete scenario is:
> > >> >>
> > >> >> -open a new connection
> > >> >> -login in the same session as the old connection (this has
> > the ISID &
> > >> >TSID)
> > >> >> -logout the old connection
> > >> >> -recover commands
> > >> >>
> > >> >> You are not supposed to be able to kill a session from outside
> > >> (at least
> > >> >> not an iSCSI defined mode).
> > >> >> You will need management support for that (SNMP?)
> > >> >>
> > >> >> Regards,
> > >> >> Julo
> > >> >>
> > >> >> Joshua Tseng <jtseng@NishanSystems.com> on 14/03/2001 17:09:48
> > >> >>
> > >> >> Please respond to Joshua Tseng <jtseng@NishanSystems.com>
> > >> >>
> > >> >> To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> > >> >> cc:
> > >> >> Subject:  RE: iSCSI: Logout needs ISID
> > >> >>
> > >> >> Julian,
> > >> >>
> > >> >> In 2.14, you state that a logout command can be
> > >> >> sent on a different connection to destroy a single-
> > >> >> connection iSCSI session.  If you have multiple
> > >> >> sessions ongoing, and the logout command is sent
> > >> >> on a different connection than the one used
> > >> >> to support the session that is to be killed, then
> > >> >> you will need ISID to distinguish the session that
> > >> >> you want killed.
> > >> >>
> > >> >> Regards,
> > >> >> Josh
> > >> >>
> > >> >> > -----Original Message-----
> > >> >> > From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
> > >> >> > Sent: Tuesday, March 13, 2001 9:57 PM
> > >> >> > To: ips@ece.cmu.edu
> > >> >> > Subject: Re: iSCSI: Logout needs ISID
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> > Josh,
> > >> >> >
> > >> >> > There is something I am missing. The Logout can be issued
> > >> >> > only after Login
> > >> >> > (authentication and the rest).
> > >> >> > The session is then implied.
> > >> >> >
> > >> >> > Regards,
> > >> >> > Julo
> > >> >> >
> > >> >> > Joshua Tseng <jtseng@NishanSystems.com> on 14/03/2001 03:56:45
> > >> >> >
> > >> >> > Please respond to Joshua Tseng <jtseng@NishanSystems.com>
> > >> >> >
> > >> >> > To:   Julian Satran/Haifa/IBM@IBMIL
> > >> >> > cc:   ips@ece.cmu.edu
> > >> >> > Subject:  iSCSI:  Logout needs ISID
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> > Julian,
> > >> >> >
> > >> >> > Section 2.14 states that the logout command may
> > >> >> > be sent on a second connection to clean up the
> > >> >> > a single connection iSCSI session.  If the reason
> > >> >> > code is 0 (close the session), then ISID is needed
> > >> >> > to identify the iSCSI session to close.
> > >> >> >
> > >> >> > Josh
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >
> > >> >--
> > >> >Mark A. Bakke
> > >> >Cisco Systems
> > >> >mbakke@cisco.com
> > >> >763.398.1054
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >>
> > >
> > >
> > >_________________________________________________________
> > >Do You Yahoo!?
> > >Get your free @yahoo.com address at http://mail.yahoo.com
> > >
> > >
> >
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
>
>
>