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

[julian_satran@il.ibm.com]

replys in text - thanks Julo

Santosh Rao <santoshr@cup.hp.com> on 09/01/2001 05:19:26

Please respond to Santosh Rao <santoshr@cup.hp.com>

To:   IPS Reflector <ips@ece.cmu.edu>
cc:
Subject:  iSCSI : Further review feedback on latest iSCSI-02.txt draft.




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.
[js] per command and it says so [/js]
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.
[js] added in 03 already
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.

[js] will fix [/js]
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).
[js]Different people have different opinions on this - even with HP - talk
to Pierre! [/js]

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.
[js] fixed already in 03 [js]
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 ?
[js] CID an timeout appear now in parameters [/js]
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.
[js] reject PDU indicates an iSCSI error, format digest etc. Handling it is
implementation dependent[/js]

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 ?
[js] the text says initiator [/js]
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" ?
[js} the error was generated by a faulty controller and I did not find any
other SCSI sense fit for it[/js]
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.
[js] only if a task is running [/js]
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

 - santoshr.vcf