Subject: Re: iSCSI: TMF valid on all iSCSI taks? ( Was: Several iSCSI protocol questions)

From: "Julian Satran" <[email-masked]>
Date: Sat, 31 Aug 2002 08:38:20 +0300

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 Management 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." <[email-masked]>
Sent by: [email-masked]
31/08/02 05:45

        To:     <[email-masked]>, <[email-masked]>, <[email-masked]>
        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
[email-masked]

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
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
> [email-masked]       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>