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

["Martin, Nick" <Nick.Martin@compaq.com>]

All,

I would hope for option 1.  There is no protection to prevent a user mode
program in a host from opening a TCP connection to the target and attempting
an iSCSI login using any SID it likes.  It could easily affect the operation
of another copy of this same application or of a kernel driver, neither of
which should have to suffer disruption.

I would further suggest, that it would be appropriate for the target to
"test" the original session to see if it is still working.  If the original
session turns out to be non-operational although not explicitly logged out,
then it could be cleaned up.  When cleanup is successfully completed, there
is no conflict and the new request becomes a fresh login.

I suggest that it is not required, but maybe not unresonable for the target
to delay the new login request while it tests and then potentially cleans up
after the previous user of this session id.  In the worst case, it might
require an initiator legitimately attempting to re-establish a session which
to it appears non-functional, to try to re-login twice (with some reasonable
delay between these).  The first time should cause the target to test the
original session, which it should after a short timeout detect to be
non-operational, triggering a cleanup.

System wide co-ordination of the use of SID within a multi-user
host/initiator will sometimes be problematic.  I would stand on the side of
protecting the current (and presumably still active) owner of the sesssion
ID from potential tresspassers.

Thanks,
Nick

-----Original Message-----
From: Jim Hafner [mailto:hafner@almaden.ibm.com]
Sent: Monday, May 21, 2001 11:15 AM
To: ips@ece.cmu.edu
Subject: iSCSI: response to second login (with same ISID)


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