Re: iSCSI : target session login behaviour

[Santosh Rao <santoshr@cup.hp.com>]

"Mudaliar, Hari" wrote:

>         I am assuming that you are referring to the creation of a new
> session with TSID=0 in your example below. Take the case of an initiator I1
> who has established a session with a target with an ISID=ISID1. What if a
> second initator I2 tries to login to the same target with ISID1? The target
> cannot decide to logout the first initiator (who already has a session
> established with ISID1) as suggested by you. 

Hari,

You may want to take a second look at my mail. It specifically refers to
the problem in the context of a given (Initiator Name, ISID). Your
example above does not fall under that category. A 2nd initiator using
the same ISID would have a different Initiator Name. (a.k.a initiator
WWUI).

The problem raised is in the context of an existing session for a given
(Initiator Name, ISID). How does a target deal with a second session
login received for the same (Initiator Name, ISID) with a NULL TSID ?

>         Also, depending on implementation, the target may realize that the
> TCP connections for a session were lost (using Keep-Alives or iSCSI NOPs
> etc.) when the initiator rebooted thus terminating the session. By the time
> a new login from the same initiator is received, the old session info may
> have been cleared.

Then again, it may not. There's 2 aspects to this issue :
1) Successful session re-logins from the rebooted host.
2) Garbage collection and cleanup of the old session resources.

(1) is a more serious issue, since the target MUST NOT reject the login
based on a pre-existing active session for a given (Initiator Name,
ISID).

(2) is handled through garbage collection algorithms, but implementation
of the proposal would help accelerate the release of stale session
resources.

- Santosh


> 
> -----Original Message-----
> From: Santosh Rao [mailto:santoshr@cup.hp.com]
> Sent: Wednesday, April 25, 2001 11:19 AM
> To: IPS Reflector
> Subject: iSCSI : target session login behaviour
> 
> All,
> 
> How should a target respond when it receives a session login  [on a new
> TCP connection] with the same (ISID, Initiator Name) as a session
> already active at the target.
> 
> Does such a login request imply :
> 
> 1) the target should perform implicit logout and re-login of the session
> identified by (ISID, initiator name) ?
> 
> 2) Or does this result in the target responding to the session login
> with :
> a login response with status class of non-zero indicating target is
> rejecting the login ?
> 
> [The draft does not describe target behaviour for this scenario.]
> 
> iSCSI session login semantics should explicitly state that the above
> scenario will result in case (1) above. i.e. when a target sees a
> session login for a given (ISID, initiator name), it MUST treat this as
> an implicit logout of any previous session active at the target for that
> (ISID, initiator name) and then, establish a new session.
> 
> This is required because the above scenario can typically occur when an
> initiator reboots without having performed a session logout on all
> active sessions.(system did not perform an orderly shutdown).
> 
> As a side note, the iSCSI draft Status Class/Codes could do with a misc
> error category along the lines of the FC "No additional Explantion"
> reason explantion. This would help deal with error conditions that don't
> come under the listed category.
> 
> - Santosh
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard