Subject: iSCSI: response to second login (with same ISID)

From: "Jim Hafner" <[email-masked]>
Date: Mon, 21 May 2001 09:15:14 -0700

Folks,

Santosh has requested a response to this question and I don't think I've
noticed an answer.  It's one of those "dot the i" things that we need to
complete.

The current thinking is that an iSCSI initiator must use a different ISID
for each session it opens with a specific iSCSI target.

We need to decide on the iSCSI target's response when the iSCSI initiator
attempts to break this rule.  The choices are:
1) REJECT the login with some error code (that the iSCSI initiator can
understand or infer to mean "ISID in use") and leave the pre-existing
session alone
2) CLOSE the pre-existing session (and abort all it's tasks) and then
process the new login fresh.

Personally, I have no strong feeling either way, but lean towards option
(1).  It's simple, clean and doesn't involve any interruption.

Anybody else got any opinions?

Jim Hafner

---

From: Santosh Rao <[email-masked]>
Date: Mon, 21 May 2001 12:33:43 -0700

> for each session it opens with a specific iSCSI target.

Jim,

Are you referring to multiple concurrent sessions from an initiator node
to a given target port above in saying that different ISIDs must be used
?

In the case where the initiator re-establishes a session to the same
target port after a power cycle, it is desirable to re-use the same
ISID, to allow for tracking of persistent reservation like properties,
correct ? (Just checking to make sure the ISID semantics did'nt change
since the Nashua discussion.)

> (1).  It's simple, clean and doesn't involve any interruption.

I'd vote for (2) for the following reasons :

a) It is possible for initiators to use the ISID as a scheme to
establish persistence of their O.S. device files. In doing so,
initiators would attempt to obtain the same ISID for a given session to
a given target ports across boots. (and rightly so, for enabling targets
to track persistent reservation like properties, etc).

In the event where the initiator went through a non-orderly shutdown
which did not close all sessions, it would attempt to re-login on
re-boot with the same ISID. If the target rejected this re-login, per
(1) (citing an invalid ISID), the initiator would no longer be able to
maintain persistence of the session to an ISID.

b) Using (2) allows the hosts to hint to the target that the previous
session is now stale and thus triggers clean-up of stale session
resources.

Regards,
Santosh

---

From: "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" <[email-masked]>
Date: Mon, 21 May 2001 21:47:50 +0200

Hello,

Before we decide one of the given 2 options we must analyze under which
conditions will initiator send the same ISID in two login.

If initiator sends the same ISID because of programattic error then in that
case option no 1 is more relevant in which target rejects the login with
some error code.

But if the initiator sends because of some digest error or it is trying to
open the same session which was ended because of some error before and
target is still in recovery stage then option no. 2 is more relevant where
target closes the pre-existing session and then proceeds for fresh login.

Regards,
Sanjeev

---

From: Stephen Bailey <[email-masked]>
Date: Tue, 22 May 2001 21:24:29 -0400

> process the new login fresh.

This provides a mechanism for rapidly reclaiming session state in the
target.  For example, if an iSCSI adapter loses its mind (I'm sure we
all believe THAT will never happen), a login with the same SID will
reclaim the target state.

This capability is provided in FC, and certainly in the early days
(which was the first 4+ years) it was very important.  If you logged
in again, you knew the target would blast anything outstanding for the
initiator.  Granted, in FCP, you had a relatively short RA_TOV, but in
iSCSI RA_TOV could be pretty long.

That said, we can provide the capability in some other way, e.g. a
flag bit.  I don't care one way or the other, but if we don't provide
an explicit way to overload a session, then logging in with the same
SID must do it.

Steph

---

From: "Matt Wakeley" <[email-masked]>
Date: Wed, 23 May 2001 13:36:40 -0700

> maintain persistence of the session to an ISID.

In this case, the initiator is at fault (it performed a non-orderly
shutdown).  Hence, when it logs in with the target, the target comes back and
says, "bad initiator, you're already logged in with me".  The initiator can
then say "oh yeah, ok, let's clean up" and perform an orderly shutdown of the
session.

> session is now stale and thus triggers clean-up of stale session

Rather than "hint", I think explicite cleaning up is better.

-Matt

---

From: Stephen Bailey <[email-masked]>
Date: Wed, 23 May 2001 18:26:04 -0400

Matt,

> then say "oh yeah, ok, let's clean up" and perform an orderly shutdown of the

What if the initiator lost its mind (hence the non-orderly shutdown)?
It doesn't seem to make sense to require a new instance of an
initiator to clean up for an old one.

What's WRONG with the FCP-style behavior (PLOGI establishes a new
session, PDISC/ADISC reconnects)?

I don't see that sanity checking the initiator is really necessary in
this case.  I know sanity checking is NICE, but getting the implicit
logout seems more important.  If Login with known SID results in an
implicit logout, the target will terminate the existing connections
for the session, and the initiator will certainly hear about this!

Steph

---

From: Santosh Rao <[email-masked]>
Date: Wed, 23 May 2001 16:50:43 -0700

Matt,

The issue spans beyond just an orderly vs. non-orderly shutdown. Some
user application may be performing raw I/O access to an iSCSI device
when the system may be shutdown. The logout operation itself may fail
(usually a don't care for the drivers.). 

What is wrong with FC semantics of a login causing an implicit logout.
It allows for clean up of old stale sessions. 

Regards,
Santosh

---

From: Santosh Rao <[email-masked]>
Date: Wed, 23 May 2001 18:26:09 -0700

> then say "oh yeah, ok, let's clean up" and perform an orderly shutdown of the

One problem with the above approach. Once the initiator has rebooted, it
has no way of cleaning the old session, since a session logout has to be
sent within the same set of TCP connections that the session was
operating on. There is no provision to logout a session from a newly
established set of TCP connection[s] for a new session upon the host's
bootup.