RE: iSCSI: reusing ISID for recovery

["Jim Hafner" <hafner@almaden.ibm.com>]

Marj,

All of your questions point out the lack of completeness in my thinking
(which is why I said "I think this gives...").

I guess I was thinking that the initiator could act like it wants to join a
new connection to the existing session, so that it can logout that session.
You're right that this is a problem for 1-connection-per-session targets,
but don't we have that problem anyway (if there is one connection and the
host looses it, what does it do now for recovery?)

As I said, I'm starting to lean a bit more toward A.  It's the cleanest and
simplest.

Jim Hafner


"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
on 08/27/2001 03:46:23 pm

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



How would the initiator log out the "dead" session?  Even if it knows a
TSID, it doesn't have any state, or any connections (assuming reboot).  Are
you suggesting the initiator perform some new sort of recovery where it
rebuilds a partial session state and "acts" like it wants to join the dead
session, for the purpose of logging it out?   Presumeably, this wouldn't
work with target implementations that only allow one connection? (see
Mallikarjun's last email) In my mind, any sort of recovery only makes sense
when there is surviving state information on both parties (I & T).  Is your
thinking different?

IMO, if option B were provided, initiator implementations would always just
turn on the "logout" bit, "just to be safe" and therefore, it would
effectively be no different than option A (just more protocol bits).

Marj

> -----Original Message-----
> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
> Sent: Monday, August 27, 2001 2:19 PM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: reusing ISID for recovery
>
>
>
> Marj,
>
> I agree (that is, I don't like option C).  I'm waffling
> between A and B.  A
> is simpler and B is "more polite".
>
> But I have a twist on option B that may make it a bit more palettable.
>
> The problem with option B is that requires extra protocol to have the
> additional bit to force the logout of the "dead" session,
> mostly because
> the initiator doesn't have the context left for the old
> session.  Suppose
> we have the target reject but in the response it puts what it
> is using for
> TSID in the usual place.  In effect, this is saying to the
> initiator "I
> already have a session in place with this ISID/TSID value".
>
> I think this gives the initiator the handle it needs to expressly do a
> logout of the old session (with a valid ISID/TSID pair) or at
> least enough
> information for the initiator to figure out what's gone
> wrong.  That is, it
> can do session recovery or whatever else is needed.  In this
> way, we don't
> need anything like a "force" bit in the login.  He has more
> steps to do,
> but they would be the same steps he would do if he just
> wanted to cleanup a
> old session he did know about.
>
> Jim Hafner
>
>