Re: iSCSI: TMF valid on all iSCSI taks? ( Was: Several iSCSI protocolquestions)

["Julian Satran" <Julian_Satran@il.ibm.com>]

Mallikarjun,

Do we really need those exceptions?

For the ABORT TASK the only ambiguity I see in the text is that of what is the result of an ABORT TASK on an ABORT TASK. I thought that the return 
of a response for each will be an indication of the action taken.

To really simplify thing and not build excessive logic around it I suggest that we say that a target will never execute a TM abort task on a TM function.

The text of 9.5.1 becomes:

Function

The Task Management functions provide an initiator with a way to explicitly control the execution of one or more Tasks (SCSI and iSCSI tasks). The Task Management function codes are listed below. For a more detailed description of SCSI task management, see [SAM2].

1  -  ABORT TASK - aborts the task identified by the Referenced Task Tag field.

2  -  ABORT TASK SET - aborts all Tasks issued via this session on the logical unit.

3  -  CLEAR ACA - clears the Auto Contingent Allegiance condition.

4  -  CLEAR TASK SET - aborts all Tasks in the appropriate task set as defined by the TST field in the Control mode page (see [SPC3]).

5  -  LOGICAL UNIT RESET

6  -  TARGET WARM RESET

7                  -  TARGET COLD RESET

8  -  TASK REASSIGN - reassigns connection allegiance for the task identified by the Initiator Task Tag field to this connection, thus resuming the iSCSI exchanges for the task.

For all these functions, the Task Management function response MUST be returned as detailed in Section 9.6 Task Management Function Response. All these functions apply to the referenced tasks regardless of whether they are proper SCSI tasks or tagged iSCSI operations.  Task management requests must act on all the commands having a CmdSN lower than the task management CmdSN. If the task management request is marked for immediate delivery, it must be considered immediately for execution, but the operations involved (all or part of them) may be postponed to allow the target to receive all relevant tasks. According to [SAM2], for all the tasks covered by the Task Management response (i.e., with CmdSN not higher than the task management command CmdSN), additional responses MUST NOT be delivered to the SCSI layer after the Task Management response. The iSCSI initiator MAY deliver to the SCSI layer all responses received before the Task Mana! gement response (i.e., it is a matter of implementation if the SCSI responses, received before the Task Management response but after the task management request was issued, are delivered to the SCSI layer by the iSCSI layer in the initiator). The iSCSI target MUST ensure that no responses for the tasks covered by a task management function are delivered to the iSCSI initiator after the Task Management response.

For ABORT TASK SET and CLEAR TASK SET, the issuing initiator MUST continue to respond to all valid target transfer tags (received via R2T, Text Response, NOP-In, or SCSI Data-in PDUs) related to the affected task set, even after issuing the task management request.  The issuing initiator SHOULD however terminate (i.e., by setting the F-bit to 1) these response sequences as quickly as possible.  The target on its part MUST wait for responses on all affected target transfer tags before acting on either of these two task management requests.  In case all or part of the response sequence is not received (due to digest errors) for a valid TTT, the target MAY treat it as a case of within-command error recovery class (see Section 5.1.4.1 Recovery Within-command) if it is supporting ErrorRecoveryLevel >= 1, or alternatively may drop the connection to complete the requested task set function.

If the connection is still active (it is not undergoing an implicit or explicit logout), ABORT TASK MUST be issued on the same connection to which the task to be aborted is allegiant at the time the Task Management Request is issued. If the connection is implicitly or explicitly logged out (i.e., no other request will be issued on the failing connection and no other response will be received on the failing connection), then an ABORT TASK function request may be issued on another connection. This Task Management request will then establish a new allegiance for the command to be aborted as well as abort it (i.e., the task to be aborted will not have to be retried or reassigned, and its status, if issued but not acknowledged, will be reissued followed by the Task Management response).

At the target an ABORT TASK function MUST NOT be executed on a Task Management request; such a request MUST result in Task Management response of "Function rejected".

For the LOGICAL UNIT RESET function, the target MUST behave as dictated by the Logical Unit Reset function in [SAM2].

The implementation of the TARGET WARM RESET function and the TARGET COLD RESET function is OPTIONAL and when implemented, should act as described below. The TARGET WARM RESET is also subject to SCSI access controls on the requesting initiator as defined in [SPC3].  When authorization fails at the target, the appropriate response as described in Section 9.6 Task Management Function Response MUST be returned by the target. The TARGET COLD RESET function is not subject to SCSI access controls, but its execution privileges may be managed by iSCSI mechanisms such as login authentication.

When executing the TARGET WARM RESET and TARGET COLD RESET functions, the target cancels all pending operations on all Logical Units known by the issuing initiator. Both functions are equivalent to the Target Reset function specified by [SAM2]. They can affect many other initiators logged in with the servicing SCSI target port.

The target MUST treat the TARGET COLD RESET function additionally as a power on event, thus terminating all of its TCP connections to all initiators (all sessions are terminated).  For this reason, the Service Response (defined by [SAM2]) for this SCSI task management function may not be reliably delivered to the issuing initiator port.

For the TASK REASSIGN function, the target should reassign the connection allegiance to this new connection (and thus resume iSCSI exchanges for the task). TASK REASSIGN MUST ONLY be received by the target after the connection on which the command was previously executing has been successfully logged-out. The Task Management response MUST be issued before the reassignment becomes effective.
For additional usage semantics see Section 5.2 Retry and Reassign in Recovery.

At the target a TASK REASSIGN function request MUST NOT be executed to reassign the connection allegiance of a Task Management function request an active text negotiation task, or a Logout task; such a request MUST result in Task Management response of "Function rejected".

TASK REASSIGN MUST be issued as an immediate command.

"Mallikarjun C." <cbm@rose.hp.com> Sent by: owner-ips@ece.cmu.edu 31/08/02 05:45

To:        <Black_David@emc.com>, <tonyb@cybernetics.com>, <ips@ece.cmu.edu>         cc:                 Subject:        Re: iSCSI: TMF valid on all iSCSI taks? ( Was: Several iSCSI protocol questions)

The intent consistently expressed in the draft is that all iSCSI tasks
are the same in that they are "managed" by the same task management 
functions (proposed exceptions below) - some iSCSI tasks are also SCSI 
tasks as a co-incidence.  Technically, I thought we had concluded in
the past that, one could use Abort Task TMF to abort Text Requests as well
(and that's reflected in 2.2.2.1, second para).  I think this is one of 
the core ideas in the draft, and not worth risking a last minute change.

Tony caught a scenario that however, I think, merits an explicit clarification in 
the draft - due to the inherent ambiguity in delivering an Abort Task
TMF to the SCSI layer that's directed at an abort operation already 
being carried out by the SCSI layer (What does a successful completion 
of the second abort mean to the original task state?  Should the first
Abort response be sent back or not?).  OTOH, there's no ambiguity
for the Task Set management case, because one knows that all the tasks
are dead once the TMF completes (SCSI tasks, iSCSI "abort" 
tasks, everything).

I suggest that we add a clarification for the "Abort-of-Abort" case, and 
a couple of others (one of which is currently covered in 9.10) in one 
new subsection.

----------------------------------------------------------------------------
9.5.7 Exceptions to Task Management Function Request usage

The following two exceptions apply to the usage of iSCSI Task Management
functions defined earlier in the document.

       a) The ABORT TASK task management function request MUST NOT
        be directed at a prior iSCSI task performing an ABORT TASK task 
        management function request.

       b) The TASK REASSIGN task management function request MUST 
       NOT be used to reassign the connection allegiance of an active text 
       negotiation task, or a Logout task.
------------------------------------------------------------------------------

If we do this, we'd have to 

    - Have the "any iSCSI task" language in section 2.2.2.1, second para to
       point to the new 9.5.7, to make the reader aware of the exceptions.
    - ditto for the first sentence in 9.5.1.
    - ditto for the "All these functions apply..." sentence later in 9.5.1 that 
       David identified.

Comments?
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com

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


> > > > 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.
> 
> And there's more text further down in 9.5.1 that seems to imply that
> one ought to be able to abort a Task Management Function.
> 
>   All these functions apply to the referenced tasks regard-
>   less of whether they are proper SCSI tasks or tagged iSCSI opera-
>   tions.
> 
> I think you've caught something we need to fix ...
> 
> > > > 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?
> 
> My mistake - I think we have some text cleanup to do, as SAM-2 definitely
> considers task management functions not to be tasks, thus avoiding issues
> of what happens when a task management function is applied to a task
> management function - I believe iSCSI needs to follow this route.  Julian?
> 
> 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
> ---------------------------------------------------
>