Re: iSCSI : target session login behaviour

[Stephen Bailey <steph@cs.uchicago.edu>]

Santosh,

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

Originally, I thought rejecting the login was the correct behavior,
and that's what I specified in the error handling pseudocode.  I
construed this as a consistency (logic) error in the target.  However,
on further thought, I've changed my mind.  I believe the correct
behavior is to perform an implicit logout (of all outstanding
connections in the session).  The target and initiator may have
different ideas about whether the connections are still live, and like
in FCP, performing an implicit logout solves this problem.  It also
provides a mechanisms for rapid, proactive recovery of session
resources when possible, which is the right thing.

> iSCSI session login semantics should explicitly state that the above
> scenario will result in case (1) above.

I agree.  This and all other possible cases.  

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

Personally, I think we should add categories for reasons we obviously
see now, AND have a no additional reason.

One peculiarity with what you're talking about above is that it should
be a login response status code which expresses this rejection.  The
login response set does not seem to have an `invalid parameter'
response for cases when the request is somehow inconsistent.

Steph