RE: Several iSCSI protocol questions

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

> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Friday, August 30, 2002 10:05 AM
> To: tonyb@cybernetics.com; ips@ece.cmu.edu
> Subject: RE: Several iSCSI protocol questions

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


Thanks.  I realized this after I sent the message.


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


Ok.


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


This contradicts the text in Section 9.5.1: "The Task Management functions
provide an initiator with a way to explicitly control the execution of one
or more Tasks (SCSI and iSCSI tasks)."  Your interpretation makes more sense
to me, however.


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


I am looking at Section 9.5.  I see "Initiator Task Tag" in the table
showing the PDU format, although it is not mentioned in the text.  Another
typo?


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


Let me give a better example: Section 9.2.2.1, AHSType, lists "60- 63
Non-iSCSI extensions".  What should the target do if it comes across an AHS
with an AHSType of 60?  Is there some other document specifying what these
codes mean?


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


Ok.


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


Ok.  The exception of course is if the opcode field is unrecognized, the
target can't be sure if the CmdSN is present in the normal place or not.


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


Makes sense.


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