Subject: iSCSI : target session login behaviour

From: Santosh Rao <[email-masked]>
Date: Wed, 25 Apr 2001 11:19:01 -0700

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

---

From: Stephen Bailey <[email-masked]>
Date: Thu, 26 Apr 2001 09:17:44 -0400

Santosh,

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

> scenario will result in case (1) above.

I agree.  This and all other possible cases.  

> 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

---

From: Santosh Rao <[email-masked]>
Date: Thu, 26 Apr 2001 11:41:20 -0700

> response for cases when the request is somehow inconsistent.

Steph,

The iSCSI draft is unclear today about the exact mechanism through which
the target indicates "invalid parameters" in response to a received
command.

1) Should it use a REJECT PDU or respond with the appropriate response
for that PDU indicating a response code of "Invalid Parameters" and a
"first bad byte" offset that indicates which parameter the target
disliked.

IMO, an "Invalid Parameters" response in the response codes is
appropriate for SCSI Command and SCSI Task Mgmt commands. [coupled with
a "first bad byte" offset.]

This is missing today. 

2) Also, as discussed above, a general "No Addional Explanation" type of
status code in the login response would cover the "misc" category.

3) There are cases of ambiguity in the usage of REJECT or SCSI Response.
Take the case of a "SNACK Reject". It is present in both the SCSI
Response (SNACK Rejected) and REJECT PDU reason code (Data SNACK
Reject). Which mechanism is to be used in this case ?

4) There is no "Status SNACK Rejected" in the REJECT PDU. 

Regards,
Santosh