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

["Mallikarjun C." <cbm@rose.hp.com>]

Julian,

>I suggest 
> that we say that a target will never execute a TM abort task on a TM 
> function.

I agree, that's what I suggested in bullet (a) of the proposed text.

We already have an exception documented elsewhere about Task Reassign
wrt Text Requests (bullet (b) - first half).

The one thing that we (I) missed in the past was about the exception related
to Task Reassign wrt Logout command (bullet (b) - second half).  We should
specify that in the draft somewhere.

To summarize, with your latest change below, 2 out of 3 exceptions are already
in the document.

> Do we really need those exceptions?

It appears that you're suggesting that we don't need to be as formal as I 
suggested, which is a separate "how" part from the "what" part.  I'd continue
to maintain that summarizing all three exceptions in one new subsection is a 
good thing. 

Regards.
--
Mallikarjun

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

----- Original Message ----- 
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: "Mallikarjun C." <cbm@rose.hp.com>
Cc: <Black_David@emc.com>; <ips@ece.cmu.edu>; <owner-ips@ece.cmu.edu>; <tonyb@cybernetics.com>
Sent: Friday, August 30, 2002 10:38 PM
Subject: Re: iSCSI: TMF valid on all iSCSI taks? ( Was: Several iSCSI protocol questions)


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