Subject: RE: iSCSI: reusing ISID for recovery

From: "Julian Satran" <[email-masked]>
Date: Wed, 29 Aug 2001 22:56:24 +0300

Marjorie,

I probably have some difficulties in explaining and you in reading ... and
that contributes to increasing distance.
Doing an automatic logout when a new session is seen can be performed by
mistake by an OS in a multi OS machine. It is just to easy to let it
through.  After a reboot the right procedure would be to login cleanly (no
previous knowledge needed). The target will ascertain that the old session
is dead and let you in.

You will need the X only when the old session is alive (answering to NOP)
but you don't know how to clean it.

Reboot behavior is close to what you have in the current draft ( a single
login needed - no X).

The difference is when you have a living connection - then you have for the
session the same thing as for a connection you have to restart it.

Julo

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>@ece.cmu.edu
on 29-08-2001 22:27:35

Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
      <[email-masked]>

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  RE: iSCSI: reusing ISID for recovery

It would help to get your message thru if you could answer our requests for
an explanation of your thinking.  We have tried several times to explain
our
logic (w/examples) but I haven't seen an example from you supporting a
scenario in which you see a problem.

If an initiator reboots, and has no context information, how can it know
whether or not a target has a pre-existing session?  Since there is no nice
way to know that, I would probably code my initiator to request a login
with
the X bit set (but as Mallikarjun said, I don't like this overloading of
the
X bit, it's a special case and makes the coding extra convoluted).  In your
preferred scenario, this would cause the target to reject the login "cause
there is no pre-existing session", and the initiator would re-issues the
login without the X bit set.  What have you saved anyone from here?  You've
just added latency to the login process.  And either way the initiator
codes
it's login after reboot, there's a presumably equal probability of
encountering this extra exchange.

I still haven't seen a plausable example where it does harm to have a login
w/ ISID=n, TSID=0 close an existing session with this initiator.  I can see
no case where this would be the wrong decision.  If "this isn't what the
initiator intended", this is a defective initiator implementation and
closing the other session at least does no harm.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: [email-masked]

> -----Original Message-----
> From: Julian Satran [mailto:[email-masked]]
> Sent: Wednesday, August 29, 2001 10:46 AM
> To: [email-masked]
> Subject: RE: iSCSI: reusing ISID for recovery
>
>
> Thanks - I started feeling bad. I could not get a message
> through. Julo
>
> "Dev" <[email-masked]> on 29-08-2001 19:03:40
>
> Please respond to <[email-masked]>
>
> To:   Julian Satran/Haifa/IBM@IBMIL, <[email-masked]>
> cc:
> Subject:  RE: iSCSI: reusing ISID for recovery
>
>
>
> Julian,
>
> >But - as this is bound to bring
> >many an initiator writer to set always
> >the bit to "just cover for the case" I propose that the
> command fails if
> >the X bit was on but there was no need for it to be on.
>
> The only need to set the X-bit (when ISID, TSID=0) could be
> to forcibly
> close a pre-existing session, if any in the target right?
>
> I agree with this proposal, as this forces the initiator to issue the
> command
> with an X-bit only when there is an error (a session already exists).
> I also like that returning an error when there is no need to
> set an X-bit,
> as it discourages the initiators to set the X-bit by default,
> for opening
> a session.
>
> Thanks
>
> Deva
> Platys Communications.
>
>

---

From: Santosh Rao <[email-masked]>
Date: Wed, 29 Aug 2001 16:54:09 -0700

Julian Satran wrote:

> through.

A multi-OS system would use a different iSCSI initiator name for each O.S.

> After a reboot the right procedure would be to login cleanly (no

Are you suggesting a combination of the existing login target behaviour
wherein the target checks the olde session if it exists when the X bit is not
set, coupled with an unconditional cleanup when the X bit is set ?

Having the target test the old session, prior to responding to a login can
bloat login time to unacceptable levels and increase system bootup time as
well as I/O scan time.

> but you don't know how to clean it.

The initiator may not know if an old session had been established by it
previously. Hence, it will either always need to set the X bit, or risk the
chance of a login reject.

What are we trying to achieve by having the target validate the initiator's
attempt to clean up an old session ? The target must trust the initiator's
decision to clean up [after first completing login authentication to avoid
malicious logout type attacks], rather than have to validate it first. Targets
should not be expected to do all this extra work of validation to protect
against initiator coding bugs.

The draft should not be trying to optimize for a coding bug scenario, wherein
the initiator accidentally re-logs in with the same (iscsi initiator name,
ISID, NULL TSID).

FC exhibits the same semantics that are being asked for here. Implicit logout
+ re-login behaviour is oft used by FC initiators. Similar login semantics
will make the life of iscsi-fc convertor products easier as well.

> Reboot behavior is close to what you have in the current draft ( a single

On a reboot, the initiator does not know if it has previously logged out of
the session prior to the reboot. Thus, it would need to clean up any stale
sessions, if they exist. Rather than attempt 2 logins [one with an X and then,
one without], the login should be allowed to imply a logout of any stale
session, if one such exists.

This issue is applicable to the reboot of initiators.

- Santosh