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

From: "Martin, Nick" <[email-masked]>
Date: Wed, 23 May 2001 17:46:04 -0500

Stephen, Santosh, and All,

I am a bit weak in my understanding of authentication.  (Is the initiator
being authenticated, or the driver on the initiator, or the application on
the initiator, or the user of the application on the initiator, etc.)  My
impression is that authentication means that something within the initiator
can somehow prove its identity to the target (and vise versa).  The
initiator is not proving its intentions.

I know from personal experience how easy it is for an authorized user to
unintentionally start a second copy of a backup program, while the tape
drive is still in use.  This should be a harmless mistake.  What kind of
traffic cop would prevent this request from making it to the iSCSI target
and terminating the session already in progress?  (Rhetorical question,
please do not describe for me such a mechanism ;)

I do not dispute the need to be able to clean up stale sessions.  I would
prefer that this be handled by timeout and/or explicit request rather than
presuming that *every* "authenticated" request to establish a session with
the same ISID is an *intentional* attempt to logout any other active session
with that ISID.

When I attempt a duplicate login for the same ISID, I would like to be able
to get an error response code for "session already logged in".  Then I would
have a choice of whether I will quit, try again later, try again immediately
with a "login unconditionally" flag, or try again with a different ISID.

In some situations, such as kernel drivers, "login unconditionally" could be
used on every attempt to save time.  The ISID's for kernel drivers may need
to be reserved (and pre-configured) so that a kernel reboot after an
ungraceful shutdown will automatically recover all the kernel's sessions.
However if two copies of an application attempt to open sessions to the same
iSCSI URL from the same host at the same time, the second should not disrupt
the first.  I'm not sure what will force them to have different ISID's, or
how they would even try to each pick a unique one.

I would like to somehow leave the [programmer of the] iSCSI initiator a
choice.

Whatever mechanism is chosen to globally assign and/or reserve ISID's within
an initiator is not specified by iSCSI and so will be a local convention.
Software not adhering to the local convention (perhaps unaware of the
correct local convention) could at least operate non-disruptively by probing
for an available ISID, but only if automatic logout of pre-existing sessions
is never done, or is selectable rather than always unconditional.

So I guess what I am suggesting is a bit in the Login PDU to select behavior
1) or behavior 2).

"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."

I now believe both are needed.

Thanks,
Nick
> -----Original Message-----
> From: Stephen Bailey [mailto:[email-masked]]
> Sent: Tuesday, May 22, 2001 9:09 PM
> To: [email-masked]
> Subject: Re: iSCSI: response to second login (with same ISID) 
> 
> 
> Nick,
> 
> > If I read Steph Bailey's comments on this right (from the 
> ERT work), the
> > target would have to authenticate the 2nd login on the same 
> ISID [as it
> > does with any other login] and only take action when 
> authentication is
> > successful.
> 
> What he said.
> 
> Steph
>

---

From: Santosh Rao <[email-masked]>
Date: Wed, 23 May 2001 19:02:05 -0700

> how they would even try to each pick a unique one.

The above scenario should not typically result in the HBA driver sending
out 2 logins on the wire, unless its open logic is broken. The open
paths are typically single-threaded and the first of the 2 applications
entering the driver open code would cause a login to go out on the wire
with the 2nd one just bumping an open_count or ref_count of some kind
within the HBA driver.

The cases when an initiator would send out 2 logins on the wire would be
ones like :

a) Bug in the initiator driver open_count logic or open locking logic.
b) Initiator's state out of sync with target's. (initiator thinks it is
logged out with the target, but target thinks the initiator is still
logged in.)
c) Prior logout operation failed at the target.
d) initiator failed to logout all sessions prior to reboot.

In cases (b), (c) & (d), the initiator does want to re-login, and logout
any stale session if active. In case (a) the driver is broken and not
much forward progress will occur with such a version.

The login semantics should be optimized for :

a) Minimal time for initiator login operation. (Should not require some
iterations of login to get a session going, while the initiator is in a
"guess an ISID" game with the target. Also, should not require a login
-> login reject -> logout of old session -> login of new session).

b) Allow a scheme for clean up of stale session resources.

Regards,
Santosh