RE: Several iSCSI protocol questions

[Black_David@emc.com]

Tony,

> 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.

Yes, but the inference is incorrect.  SAM-2 defines "linked command" as:

  3.1.58 linked command: One in a series of SCSI commands processed by a
  single task that collectively make up a discrete I/O operation. In such
  a series, each command is represented by the same I_T_L_x nexus, and all,
  except the last, have the LINK bit in the CDB CONTROL byte set to one.

Linked commands are always sequential, not concurrent, as they use the same
I_T_L_x nexus - see the example in Section 5.7.2 of SAM-2.  Only one command
from a set of linked commands is active at any point in time, and hence the
ITT for the linked commands uniquely identifies it.  Linked commands are
rarely used in practice, FWIW.

> --- 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?

It shouldn't - if there's a protocol error, the Task Management function
cannot be processed.

> 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?

No, SCSI task management functions operate on *SCSI* tasks, not *iSCSI*
tasks, and a task management function is not a *SCSI* task - see SAM-2.

> If not, then what is the
> appropriate Task Management Function Response for an ABORT TASK that
> attempts to operate on another Task Management Function?

That can't happen.  The only task management function that could possibly
attempt "to operate on another Task Management Function" is ABORT TASK, but
it identifies the task to be aborted by an Initiator Task Tag, something
that Task Management Functions *do not* have - see Section 9.5 of the iSCSI
draft.

Beyond this, task management functions generally succeed when the
task set is empty.  In particular, ABORT TASK succeeds when the task to
be aborted is not in the task set - see Section 6.2 of SAM-2.

> --- 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 unitsof 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).

The former - whether an AHS is present is specified with each PDU
definition.

> 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?

Such a target is broken (if an AHS is allowed, the target has to
expect that it might be present and be prepared to do whatever
is necessary), and should be fixed.

> --- 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?

Returning the Reject earlier will probably be appreciated by the
initiator.  There's no requirement to wait.

> 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?

Ignore it.  Section 2.2.2.1 says:

  For non-immediate commands, the CmdSN field can take any value from 
  ExpCmdSN to MaxCmdSN inclusive. The target MUST silently ignore any 
  non-immediate command outside of this range or non-immediate dupli-
  cates within the range. 

"silently" is the key word in this text.

> --- 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?

Not exactly.  The problem is that one can get into weird situations
in which the two ends of a TCP connection have different views on
whether it's been terminated.  If the TCP connection is alive,
Logout for that connection should be sent on that connection.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------