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

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

Steph, Santoch, Nick, and All,

As the one who posted this question in the first place, I think it's time
for me to chime back in.

I see valid arguments for both behaviors and Nick supporting a feature to
enable that.

There are two scenarios we're dealing with.
(1) Initiator (for whatever reason) unknowingly reuses an active ISID.
Nick's example of the user application using a generic NIC is a good one (I
programmed a Java Initiator, and that's about as high up in the application
stack as you can get!).
(2) Error scenario of some sort, where the initiator and target don' agree
on state for the "live ISID".

The former begs for "login reject, ISID in use".  The latter begs for error
recovery.

The way I see it, however, is that the second case should be dealt with in
the context of error recovery (independent of the ISID question).  If we
don't have any way to cleanup a target's session without having a live
connection in that session to do so, then we're missing a major piece of
the iSCSI puzzle.  We have to have a mechanism for the target to clean up
session resources that are lost to the host.  Isn't there some timeout the
target can rely on here?  Isn't there a mechanism for the initiator to say
"I lost my brains on that session, so you can clean up"?  (Isn't this last
what Nick's Login PDU bit would say?)

So, I'd recommend we use "login reject, ISID in use" for the reused ISID.
We solve the "error case" as an error case (who's doing these scenarios?).
In the error case, the "login reject" is one form of error detection (there
are others).   Santosh argues that login shouldn't take too long, but error
recovery can take as long as it should to clean things up, even if it has
to go through "login->reject->cleanup->login" during boot.

One final note. The comparison with FCP behavior is only partially valid.
The problem is that FC login occurs at an extremely low level of the wire
protocol where the NICs have control of things in firmware (typically), or
at least down in the lowest level of the kernel.   In other words, that
process is owned by one self-contained system component.  For iSCSI, this
login, as has been noted, can occur anywhere and everywhere
(simultaneously) in the application stack.  So, I wouldn't necessarily
recommend that we model FC behavior here.

Jim Hafner