iSCSI : Further review feedback on latest iSCSI-02.txt draft.

[Santosh Rao <santoshr@cup.hp.com>]

Julian/All,

More feedback on the latest iSCSI draft (02.txt. dec 30, '00) :

Section 1.2.2.3. Data PDU Numbering
============================
What is the scope of DataRNs ? Is this maintained per task or per
connection or per session ? This should be explicitly stated in this
section as is done in earlier sections for CmdRN and StatRN.

Section 1.2.8.3. Max iSCSI PDU Size
============================
The login parameter for the Max iSCSI PDU Size as described in
this section is missing in the Login/Text keys in Appendix C.

Section 2.5. SCSI Task Management Command PDU
=======================================
The "Logical Unit Number" field in the figure should state
"Logical Unit Number or reserved (0)" since the LUN is a don't
care value in case of the Target Reset task mgmt command.


Section 2.6. SCSI Task Management Response
==================================
The referenced Task Tag field can be removed since the
"No Task Found" response error is not valid.
(A Target should respond with an accept for an Abort Task
request specifying an invalid Initator Task Tag).


Section 2.7 READ SCSI Data PDU
==========================
1) The READ SCSI Data PDU does not contain a Target
Task Tag. Hence, when initators acknowledge  DataRNs
using NOP-OUT, targets will have to lookup the I/O based
on its Initator Task Tag. It would be simpler and more optimal
for targets to have a single lookup mechanism based on their
Target Task Tags. This would also be in sync with Fibre Channel
semantics where target lookups are based on only RX_ID.
This is possible if Target Task Tags are used for READ SCSI
Data PDUs.

Section 2.17 Asynchronous Event
=========================
1) "Target requests Logout on this connection" iSCSI event
indicator. Why not just allow the target to originate a Logout
as is done in Fibre Channel ?

Besides, this AEN does not meet the requirement.
How does the target convey the CID of the connection to be
logged out ?

I do not think SAM-2 lays any guidelines for how the SCSI
 interconnect protocol handle its native PDUs. (i.e. non-scsi
operations).
Fibre Channel allows unsolicited inbound traffic for ELS and
BLS commands and allowing Logout and NOP-OUT
(perhaps better thought of as a NOP command) commands to
be originated by targets would be desirable and would get rid of this
particular AEN iSCSI event indicator.

Section 2.19. Reject PDU
===================
What is the value-add from copying the received iSCSI header into
the Reject PDU ?
Returning the Initiator Task Tag alone in the Reject PDU allows the
initiator to look up its per-task data structure to determine what
iSCSI PDU was transmitted on the Initiator Task Tag.

2) Is the reject PDU intended to be used for both SCSI and non-SCSI PDUs
?
The REJECT PDU should be used to reject ALL non-scsi PDUs. For scsi
PDUs, sending a response back thru the standard response PDUs
(SCSI response or SCSI Task Mgmt response) would be preferrable since
this allows the communication of specific information related to the
failure
of the SCSI PDU in the respnse Data or Response Code fields of the SCSI
Response or SCSI Task Mgmt Response.

3) More detailed Reason Code/Reason Explanation fields in the Reject
PDU is highly desirable. This will greatly help enhance the interop
abilities
of initiators and targets by being able to isolate quickly the reasons
for
a PDU Reject.

I will send in further comments to the reflector on desired reason code
and reason explanations for the Reject PDU.


Section 4.4. Format Errors
====================
Quoting from the draft :

"When a session is active whenever an initiator receives an iSCSI PDU
 with a format error, for which it has an outstanding task, it MUST
 abort the target task and report the error as a SCSI check condition
 status with a sense key of 4h (hardware error)."

Is the above referring to an initiator's action or a target's ?

What is the reasoning behind this ? It seems to complicate Format Error
Handling with no clear benefit. Is it the expectation that iSCSI
initiators
will fake a format error as a CHECK CONDITION back to the SCSI
Layer ? If so, why ? And why the choice of "Hardware Error" ?

Last, but not the least, the above statement is referring to all iSCSI
PDUs
and advocates that iSCSI initiators must fake a CHECK CONDITION
back to the SCSI layer on any format error of any iSCSI PDU.

This is not applicable for non-scsi iSCSI PDUs which have no SCSI
context. I believe the REJECT PDU should only be used for non-scsi
PDUs since Rejects to SCSI PDUs will need a different type of reason
code/explanation information best fitted into the existing SCSI Response

PDUs.

Thanks,
Santosh Rao
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard