Several iSCSI protocol questions

["Tony Battersby" <tonyb@cybernetics.com>]

Hi,

I have a few general iSCSI protocol questions.  All questions are based on
Draft 15.

(Sorry if this message is a duplicate.  I sent it once before but I don't
think it got through.)

--- Initiator Task Tag uniqueness ---

Section 2.1, "A SCSI task is a SCSI command or possibly a linked set of SCSI
commands."

Section 2.2.2.1, "Some iSCSI tasks are SCSI tasks, and many SCSI activities
are related to a SCSI task ([SAM2]). In all cases, the task is identified by
the Initiator Task Tag for the life of the task."

Does the above imply that the initiator must (or can?) use the same
Initiator Task Tag for all SCSI commands in a given linked set of SCSI
commands?  If so, then a given Initiator Task Tag may not uniquely identify
a particular SCSI command.  In this case, if the target receives an
unsolicited data PDU, it would have to rely on the requirement that
unsolicited data PDUs must be sent in the same order as the commands were
sent in order to identify the SCSI command associated with the unsolicited
data PDU.  My question: what is to prevent the target from associating an
unsolicited data PDU with the wrong command if the target discarded one of
the linked command PDUs in the task due to a digest error?

--- Task Management Functions ---

Section 9.5.1, "For all these functions, the Task Management function
response MUST be returned as detailed in Section 9.6 Task Management
Function Response."  Does this mean that a Task Management Function with one
of the listed functions cannot be rejected with a Reject PDU if some other
field of the PDU has a value that is a protocol error?

If I read the spec correctly, the ABORT TASK, ABORT TASK SET, CLEAR TASK
SET, and LOGICAL UNIT RESET functions operate on iSCSI tasks that:

1) Have a CmdSN that is lower than the CmdSN of the Task Management
Function, AND
2) Have a valid LUN that is equal to the LUN of the Task Management Function

Since the Task Management Function itself has a CmdSN and valid LUN, can one
Task Management Function affect (abort) another?  If not, then what is the
appropriate Task Management Function Response for an ABORT TASK that
attempts to operate on another Task Management Function?

--- AHS ---

Section 9.2.1.5 TotalAHSLength:

"Total length of all AHS header segments in four byte words including
padding, if any.

The TotalAHSLength is used only in PDUs that have an AHS and MUST be 0 in
all other PDUs."

For the first sentence, I recommend changing the wording to emphasize the
fact that the length is not in bytes (something like "... segments in units
of four byte words ..." with an example given).  I missed this fact the
first time I read it.

The second sentence is confusing since it is not spelled out which PDUs have
an AHS.  Is this sentence specifying a requirement that some pre-defined
list of PDUs that do not have an AHS MUST have TotalAHSLength equal to 0, or
is the sentence simply stating that a nonzero TotalAHSLength implies that an
AHS is present?  In the former case, the list of PDUs not allowed to have an
AHS can be determined by looking elsewhere in the spec (Task Management
Function Request, Task Management Function Response, R2T, Logout Request,
Logout Response).

Next question: if an AHS is present in a PDU allowing it, but the target
does not know what to do with it, should the target reject the PDU or ignore
the AHS?  I noticed that some older drafts had a bit that indicated which to
do, but the bit was dropped in more recent drafts.  If the target should
reject the PDU, what Reject reason should be used?

--- Reject ---

If a target decides to reject a non-immediate command when it can determine
the CmdSN of the command being rejected, should the target return the reject
response immediately, or should the target defer the reject response until
the command being rejected would have been delivered for execution based on
its CmdSN?  If the CmdSN of the command being rejected is outside the valid
command window, should the target ignore the PDU and not return the Reject
response, or should the target return the Reject response anyway?  My guess
is that any of these options are valid, but I want to make sure.  In any
case, it seems that the initiator needs to be prepared to receive multiple
Reject PDUs from the target for a single command if the initiator
re-transmitted the command due to a timeout before receiving (or noticing)
the reject.

--- Logout ---

Section 9.14, "A Logout for a CID may be performed on a different transport
connection when the TCP connection for the CID has already been terminated."
Was this intended to imply that a Logout for a CID MUST be performed on the
same transport connection when the TCP connection for the CID has _not_
already been terminated?


Thanks,
Anthony J. Battersby
Cybernetics