Subject: iSCSI : Login Response PDU Issues.

From: Santosh Rao <[email-masked]>
Date: Sun, 07 Jan 2001 18:33:42 -0800

Julian,

Some concerns regarding the Login Response PDU section of the latest
iSCSI draft :

Section 2.11.3. Login Response Status
======================================
1) Should targets use a REJECT PDU or Login Response PDU with a status
of "reject login" to indicate Login Reject ? Section 2.11.3 and 4.4
contradict
each other on this subject.

A standard REJECT PDU used to reject ALL non-scsi PDUs
[and ONLY non-scsi PDUs] would be desirable and would provide
the following benefits :

o       Allows more specific error information to be conveyed
        within SCSI Task Mgmt response PDUs and SCSI Response
        PDUs, on a reject of SCSI Task Mgmt Cmd or SCSI Command.
        (thru the Response Data for Scsi Response PDU and
         Response field for SCSI Task Mgmt response PDU).

o       Consistent with Fibre Channel semantics for the standard
         LS_RJT for all ELS'. This also allows for easy mapping
         from iSCSI Response PDUs to FC ELS responses and vice versa
         in iSCSI-FC bridges.
         (since an iSCSI-FC bridge would be mapping certain types of
         operations and their responses from one protocol to another
like
          Login. Logout, NOP-OUT, etc.)

o        REJECT field in the Login Response PDU can be made reserved.

2) Whatever the mechanism that will be finally used for login rejection
[be it the REJECT PDU or "reject login" in login response PDU], it
should
make provisions for detailed reason codes and reason explanations that
allow
the initiator to determine the cause of the rejection. This does not
currently exist in the draft.

3) Quoting from the draft :

"In the case that the Status is reject login the initiator should
immediately
close down its end of the TCP connection, thus freeing up the target's
port for some other connection."

On a REJECT, initiators may wish to retry Login. [perhaps, with a
modification to their Login Command PDU or TEXT parameters .

Perhaps, the word "may" might be a better fit instead of "should" here.

Thanks,
Santosh

---

From: Matt Wakeley <[email-masked]>
Date: Tue, 09 Jan 2001 15:25:18 -0800

> Perhaps, the word "may" might be a better fit instead of "should" here.

What is so bad with always closing a TCP connection when a login is rejected
and opening a new TCP connection when issuing a login?  Makes it simple.  Only
one way to do things.  Only one path to test.

-Matt Wakeley
Agilent Technologies

---

From: Matt Wakeley <[email-masked]>
Date: Tue, 09 Jan 2001 15:29:28 -0800

Santosh Rao wrote:
> contradict each other on this subject.
> 

There already is one.  Check out section 2.19 "Reject".

> currently exist in the draft.

Perhaps you should provide a detailed list of reason codes and reason
explanations you would like to see.

-Matt Wakeley
Agilent Technologies

---

From: Santosh Rao <[email-masked]>
Date: Tue, 09 Jan 2001 19:19:23 -0800

> There already is one.  Check out section 2.19 "Reject".

The above comments are questioning whether to use REJECT PDU (as defined in
section 2.19) or to use the "reject login" Login response PDU. It seems like
there's redundant solutions being provided here. The "Status" field in the
Login Response should be removed since a login reject should be conveyed
through the REJECT PDU.

Additionally, the above also questions the use of REJECT PDU for scsi PDUs
since their reject could do with more specific error information conveying
the reason for the failure. REJECT PDU would be desirable for use with
non-scsi PDUs along the lines of a standard LS_RJT for all ELS in fibre
channel.

Thanks,
Santosh

---

From: Pierre Labat <[email-masked]>
Date: Tue, 09 Jan 2001 23:20:11 -0800

> one way to do things.  Only one path to test.

As it is not on the performance path i prefer to keep it simple too. If the
target
doesn't close the connection after rejecting the login when will it do it? It
must
add some code to manage such kind of things, better to avoid.

Regards,

Pierre