Re: [Fwd: Review feedback on draft-ietf-ips-iSCSI-02.txt]

[julian_satran@il.ibm.com]

Santosh,

That is in my - "to consider" stack and that is the reason you did not hear
back (don't get nervous!).
Bu here is my position:
(interspersed in text)

Thanks,
Julo

Santosh Rao <santoshr@cup.hp.com> on 23/12/2000 02:06:03

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

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   santoshr@cup.hp.com
Subject:  [Fwd: Review feedback on draft-ietf-ips-iSCSI-02.txt]




Julian,

I am re-sending this message to you since I did'nt hear any response back
on this.
Your response on some/all of these issues would be highly appreciated.

Thanks and Regards,
Santosh Rao


Santosh Rao wrote:

> Julian/All,
>
> Enclosed is some review feedback on  draft-ietf-ips-iSCSI-02.txt.
>
> Thanks,
> Santosh Rao
>
>
------------------------------------------------------------------------
> Reference : draft-ietf-ips-iSCSI-02.txt
> ========================================
>
> o       When command numbering is turned off (by setting InitCmdRN to 0),
>         what is the value of CmdRN to be used for commands ?
>         It would be preferrable to use a "don't care" value for the CmdRN
>         like 0xFFFFFFFF instead of using 0 which is intended to indicate
>         Immediate Delivery.
>
If you don't use numbering CmdRN is a reserved field. You are only after
avoinding a test on the target?  If the initiator is not using numbering
having each command delivered as imediate convey the right intent.


> o       Normally, command ordering is enforced by the layer above
>         SCSI (ex : file systems, volume managers, etc) and in such
>         cases command ordering should not be required.
>         The spec iSCSI-02.txt states that "iSCSI initiators MUST
implement the
>         command/request numbering scheme if they support more than 1
connection
>         per session" (Section 1.2.2.1).
>         Can the use of command numbering be made optional (using the
existing
>         mechanism of setting InitCmdRN to 0 during LOGIN) if the
initiator
>         stack does not require command ordering, but has chosen to use
>         multiple connections per session ?
I don't see how this will ever work. How can the layer above enforce
ordering and let iSCSI mess it up?

>
> o       The reference to "Response Length" and "Response Data" in the
SCSI
>         Response PDU (Section 2.3) is unclear about Response Data. Does
this
>         refer to the same semantics as the Response Data used in Fibre
>         Channel's FCP_RSP terminology ?
>         Where is the Response Data defined in the standard ?
>

Will clarify in the next text

> o       It would be desirable to have a set of error codes in the SCSI
Response
>         PDU that reflect any iSCSI PDU errors such as :
>         - iSCSI cmd PDU fields invalid
>         - Data Length different from desired length requested in R2T
>         - Data Relative Offset different from buffer offset requested in
R2T
>         ...
>

Will clarify how this is done in the next draft.

> o       A standard REJECT response would be highly desirable for all
command
>         type PDUs (ex : LOGIN, LOGOUT, TEXT, NOP).
>         The REJECT response could include reason code and reason
explanations
>         which allow identification of the reasons for the REJECT.
>

as above (closer to a common iSCSI reject than the current command not
understood)

> o       Section 2.1.5 :
>         "The initiator assigns a task tag to each SCSI task that it
issues."
>         The above should read ..."to each task that it issues", since
initiator
>         task tags are also used for non-scsi tasks like LOGIN, LOGOUT,
NOP,
>         TEXT, etc.

Thanks - will do

>
> o       What are the "don't care" values to be used for ExpCmdRN and
MaxCmdRN
>         when command numbering is turned off ? Can this be explicitly
specified
>         in the draft ?
>
Will do (all reserved fields MUST be 0 unless specifically stated
otherwise)

> o       iSCSI should avoid interpreting Sense Data and creating/using any
iSCSI
>         specific check conditions, if possible. iSCSI specific errors
should be
>         returned in Response Data in the SCSI Response PDU (when the
response
>         data gets defined). THis allows for cleaner layering between SCSI
and
>         iSCSI.
>

That is so now and will be even cleaner in the next text.
> o       The MaxCmdRN provides a form of dynamic queue depth management at
the
>         target end, which complements the standard SCSI Queue Full
mechanisms.
>         However, turning off command numbering (as in the case of single
>         connection per session) also implies that this mechanism is
un-usable.
>         Any thoughts on some alternate schemes that would work even when
using
>         single connections per session ? (Could command numbering be
turned on
>         even for single connection sessions with a different meaning
implying
>         use for queue depth management only and not ordering ?)

The command numbering can be used for queue management even if you have a
single connection.
IF THE WG FEELS STRONGLY ABOUT IT THEN WE COULD raise command numbering to
a MUST implement for every initiator and target.

> o       Section 2.7. The Response field in the SCSI Task Management
Response
>         PDU could do with some enhancing.
>         - The "No Task Found" response can be removed since the target
should
>           not REJECT an Abort Task  received for a non-existent task.
Targets
>           should respond with "Function Complete" for an Abort Task sent
on a
>           completed task. This ensures that failure of Abort Task does
not
>           trigger a higher level of error recovery from the initiator.
>
Pierre Labat found this hole. An abort can come after a reset by some other
initiator.

>         - The following responses could be considered for addition to
>           the list :
>           i)    "No such LUN" when Abort Task Set, CLear Task Set or LUN
Reset
>                 is attempted on an invalid LUN.
>           ii)   "Logical Busy" when a 2nd task management function is
attempted
>                 while a prior conflicting task is in progress.
>                 (ex: attempting LUN Reset while Target Reset is
>                  in progress, etc.)
>          iii)   "Function Not Supported" to allow targets to indicate no
support
>                 for certain task management requests. (ex: target reset
!).
>                 This should be treated differently from "Function
Rejected"
>                 which could be used to indicate an invalid request.
>
Those are allready fixed in the next text (some other way though).
> o       It is still not clear as to why WRITE SCSI Data PDUs need to
specify
>         the LUN. (This is not done in the case of fibre channel.)
>
To let the targets choose liberaly the Target Task Tag
> o       Section 2.12 only specifies version major and version minor. A
Version
>         High and Version Low would help initators and targets negotiate
amongst
>         a range of versions. The major and minor versions can be made 4
bits in
>         size, using the same length as is currently used for version
major and
>         version minor. (There have already been requests for this on the
>         reflector).
Will consider
> o       Section 2.14.
>         The NOP Response PDU should allow a REJECT response for
>         the NOP to deal with an invalid NOP command PDU.
>
All rejects will be treated equal

> o       Section 2.14. NOP Response PDU.
>         "The target SHOULD also duplicate as much of the initiator ping
data as
>         allowed by a configurable target parameter".
>         Is this referring to the PingMaxReplyLength login key ? If so,
the
>         initiator should not be sending more than this length in its NOP
>         command PDU payload. Hence, the above could be re-worded to
indicate
>         that initators should honor PingMaxReplyLength and targets SHOULD
>         duplicate all of the initiator ping data in their response.
>
So you are suggesting that the targets should not respond at all or reject
a ping that does not comply with your rule? Our design rule was to be only
as restrictive as needed.
> o       Section 2.15.
>         "The logout command is used by an initiator to 'clean up' the
target
>         end of a failing connection and enable recovery to start".
>
>         This should be re-phrased since a logout can be used as a form of
a
>         graceful close of the I-T nexus.
>
Will consider
> o       Section 2.17.
>         "The buffer offsets and lengths for consecutive PDUs should form
a
>         continuous range".
>
>         Does the above imply targets are expected to request data
in-order on
>         R2Ts ? This is not a requirement for Fibre Channel currently. If
this
>         is not the intent, then, the above should be re-phrased to make
this
>         more clear.
>
No - it is meant to convey that they should cover the whole range (will
restate)

> o       Section 2.17.
>         "The present document does not limit the number of outstanding
data
>         transfers".
>         This is not true, since MaxOutstandingR2T (as defined in Annexe
C) is
>         used to pre-negotiate the limit on the number of outstanding data
>         transfers.
>
Will fix wording.

> o       Section 2.17.
>         "All outstanding R2T should have different target transfer tags".
>         Target transfer tags are used to track the state of the entire
task
>         and should be the same value for all phases of that task.
>         The ability to have multiple concurrent R2Ts seems to call for an
>         additional qualifier for the task such as a task sub-id. Target
>         firmware would typically use the target task tag to lookup a per
I/O
>         data structure that is tracking the state of that task. In order
to
>         track multiple outstanding R2Ts within the same task, a different
field
>         should be used. (something equivalent to a Sequence ID in Fibre
Channel,
>         if the target task tag were to be thought of as the RX_ID of
fibre
>         channel.)

That's why you have the LUN.  However within this any target can do as it
pleases and the initiator will only echo the tag.

 - santoshr.vcf