Subject: iSCSI: Need to Kill Session from Surviving Node

From: "John Hufferd" <[email-masked]>
Date: Wed, 14 Mar 2001 10:30:50 -0800

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?

.
.
.
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: [email-masked]

Julian Satran/Haifa/IBM@[email-masked] on 03/14/2001 08:31:19 AM

Sent by:  [email-masked]

To:   [email-masked]
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 <[email-masked]> on 14/03/2001 18:17:14

Please respond to Mark Bakke <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked]
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

[email-masked] 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 <[email-masked]> on 14/03/2001 17:09:48
>
> Please respond to Joshua Tseng <[email-masked]>
>
> To:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
> 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: [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, March 13, 2001 9:57 PM
> > To: [email-masked]
> > 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 <[email-masked]> on 14/03/2001 03:56:45
> >
> > Please respond to Joshua Tseng <[email-masked]>
> >
> > To:   Julian Satran/Haifa/IBM@IBMIL
> > cc:   [email-masked]
> > 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
[email-masked]
763.398.1054

---

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 14 Mar 2001 12:15:45 PST

>Initiator to "Kill" the Session to the Failing Target Node?

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.
[email-masked]

---

From: "Somesh Gupta" <[email-masked]>
Date: Wed, 14 Mar 2001 17:40:49 -0800

Do you need both a "warm-reset" and a "cold-reset"?
The "warm-reset" seems to be an over-optimization.

Somesh

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Mallikarjun C.
> Sent: Wednesday, March 14, 2001 12:16 PM
> To: [email-masked]
> Subject: Re: iSCSI: Need to Kill Session from Surviving Node
>
>

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: "Somesh Gupta" <[email-masked]>
Date: Wed, 14 Mar 2001 20:25:58 -0800

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

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Mallikarjun C.
> Sent: Wednesday, March 14, 2001 7:31 PM
> To: [email-masked]
> Cc: [email-masked]
> 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

---

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 14 Mar 2001 19:31:29 PST

Somesh,

--
Mallikarjun 

Mallikarjun Chadalapaka