Comments to draft-ietf-ips-iSCSI-00.txt

[Matt Wakeley <matt_wakeley@agilent.com>]

Comments to draft-ietf-ips-iSCSI-00.txt:

* Section 1.2, Concepts:
"SCSI RPC model" is not defined and I couldn't find it in SAM.

* Section 1.2.1, Layers, last part should say:
"iSCSI initiators and targets MUST support at least one TCP connection,
and SHOULD support several connections in a session."

* Section 1.2.2.1 Command numbering
The section does not specify what the target is to do with command
numbering.  The iSCSI layer must not deliver commands to the SCSI
delivery port until all lower numbered commands have been delivered
to the SCSI delivery port (or something along those lines).
Also, the section needs to be broken into smaller paragraphs.

* Section 1.2.4, Login:
"A session is used to identify to a target all the connections with
a given initiator."

This is not true.  A session is used to identify
all the connections in a logical connection between the initiator
and the target.  There could be more than one session between an
initiator and a target, in which case a session does not identify
"all" the connections.

* Section 1.2.6 Full feature: should say (somewhere in the middle)
"If an initiator issues a WRITE command, the initiator must send
the data, if any, for that command and the target MUST return the
status and R2T (if any) over the same TCP connection that was used
to deliver the SCSI command." [ add the text "and R2T (if any)".

Also, this is another paragraph that is too long and should be
broken into smaller pieces.

* Section 1.2.6 Full feature, tags:
"Target tags for pending commands are unique LU-wide for
the session; together with the LUN they form a target-wide unique
composite tag for a session."

I don't see why this is specified.  The target should be free to
choose how it wants to allocate Target Tags.  Indeed, in section
2.19.2 it says "There is no protocol rule about Target Transfer Tag
but it is assumed that it will be used to tag the response data to
the target (alone or combination with the LUN)."  I like this latter
rule better.

* Section 1.2.6 Full feature, unsolicited data:
"If the amount of data exceeds the amount allowed for unsolicited
write data, the specific connection MUST be stalled - no new data
will be sent on the specific connection until initiator receives
an R2T iSCSI PDU from the target."

Why must the connection be stalled?  If the initiator has sent the
maximum amount of allowed unsolicited data, the I/O by definition
becomes a solicited data only I/O, and the unsolicited I/O rules
apply.  It is undesirable to not be able to send data for other
I/Os on this connection simply because one I/O has been sent the
maximum amount of unsolicited data that's allowed.

* Section 2.1.1, F bit:
The definition of the F bit is wrong.  It must be zero always.
The algorithm to figure out the particular urgent TCP implementation
is correctly specified in section 1.2.9.  All the "F" bits in the
iSCSI headers should be changed to "0" (zero).

* Section 2.1.2 Opcode:
"The initiator MUST NOT send target opcodes and the target MUST NOT
send initiator opcodes."

The target should be allowed to "ping" the initiator to see if
it is still alive.  Also, the target should be able to "logout" with
the initiator (FC allows this).

* Section 2.1.6 Initiator Task tag
"To enable gateways to older networks to operate without retaining
per/LU state" this text should be deleted.  There does not need to
be a reason to why the target may want to restrict the size of the
initiator task tag.

* Section 2.1.7 Digests
There must be a mechanism in the iSCSI header to identify the
location and lengths of the header and data digests to avoid
login context lookups for every data PDU - especially if they
can vary in size.

* Section 2.2.5 Transfer Length
"Upon completion of a data transfer, the target will inform the
initiator of how many bytes were actually processed (sent or
received) by the target."

Should indicate that this is specified via residual counts, not
actual counts.

* Section 2.3 SCSI response
The "Basic Residual Count" and the "Bidi Residual Count" fields
need to be swapped because the Target Task Tag is required in the
Data PDU (see comment below)

* Sections 2.4 and 2.5 (NOP) should be deleted because they
duplicate Sections 2.13 and 2.14.

* Section 2.8 SCSI Data PDU
The field starting at offset 20 needs to be the Target Task Tag
because if a NOP is to be sent, the target will need the Target
Task Tag to match it up with an I/O.

The field starting at offset 24 should be called "DataRN/StatRN"

The "iSCSI Status" field should be deleted because it doesn't
exist in the Status PDU.

* Section 2.8.5 (DataRN)
"...  for a maximum of 32 incoming data PDUs."
Section 1.2.2.3 specifies that this is negotiated at login.

* Section 2.13 NOP command
The NOP command should be allowed to be originated by the target
to determine if the initiator is still alive and well.

The field starting at offset 20 needs to be called the
Target Task Tag for those NOPs that are sent in response to a
Numbered Data PDU. [ Perhaps the initiator should send a NOP
Response instead of a NOP command in response to a numbered
data PDU? ]

"unlike the NOP message, NOP has an Initiator Task Tag and can be
delivered in order."  I have no idea why this is in here.  Only
commands need to be delivered in order.

"...  the initiator may conclude that there is a problem with the
connection."  Or, there could be a problem with the target itself...

"... initiator will then close the connection and may try to
establish a new connection."  will?  does will mean "must" or "may"?

"The NOP command with the P bit not set MAY be used to acknowledge
data received from a target (data-ack)." May?  what other mechanism
is there?
"In this case, the command caries the same Initiator Task Tag as the
data it acknowledges" it must also carry the Target Task Tag.

"and the CmdRN field MUST be zero. The field ExpStatRN/ ExpDataRN is
then understood to be ExpDataRN."
There is no "ExpStatRN/ExpDataRN" field.  They are two separate
fields in the described header.

* Section 2.13.1 This should be named the "Ping" bit, not Poll.

Section 2.14 NOP Response
The field starting at offset 20 needs to be called the
Target Task Tag for those NOPs that are originated by the target
for the purposes of determining if the initiator is still alive
and well.

* Section 2.17 Logout command
The logout command should be allowed to be originated by the target
to disconnect under error or other conditions.

* Section 2.19 R2T
"An R2T MUST be answered with one and only one iSCSI Data-out PDU
with matching Target Task Tag."

The initiator should be allowed to send as many Data PDUs
as it wants, as long as they are within the range of data requested
by the R2T.  For example, suppose the R2T was for a 1Meg transfer.
The initiator must be allowed to send smaller sized Data PDUs so that
it can interleave commands or other iSCSI messages with the data.

-Matt Wakeley
Agilent Technologies