RE: iSCSI: abort task & abort task set

["Buck Landry" <blandry@Crossroads.com>]

One barely-related comment, since this section is apparently in flux.

The Task Management Function Request is supposed to be applicable to both iSCSI and SCSI tasks, according to the v9 draft, section 3.5.1.

I take it that ABORT TASK SET, CLEAR TASK SET, and LOGICAL UNIT RESET do affect *iSCSI* tasks that have a LUN field set?  AFAICT this includes only earlier instances of these same aborts and ABORT TASK .. still, it feels slightly weird to abort aborts..

This seems to happen, for example, if an immediate abort-task-set with CmdSN 'i+1' was sent ahead of a non-immediate abort-task-set with CmdSN 'i'.  In this case the non-immediate abort is aborted, and a response is returned for the immediate abort.  I don't need additional comment on this (unless I'm wrong, of course)

I understand that TARGET WARM RESET blows away *all* pending iSCSI tasks (logout PDUs, etc) from all initiators?  That seems like a little bit of overkill, inducing extra unneeded errors, but I'm assuming there's a decent reason for it, like consistency or something.
--Buck


-----Original Message-----
From: Mallikarjun C. [mailto:cbm@rose.hp.com]
Sent: Friday, December 14, 2001 3:16 PM
To: somesh_gupta@silverbacksystems.com
Cc: ips
Subject: Re: iSCSI: abort task & abort task set


Somesh,

One comment.

> 1. For targets that only support single connection per session, and do
> not support error recovery, would it be ok to send the status for the
> task management command without having to wait for the status ack
> for all previously sent statuses?

   I think it's okay. (There are other subtle areas here even for
ErrorRecoveryLevel=0 -
   how quickly should a connection/command be failed after the first error
that
   requires recovery?  If there are posted good statuses after the lost
status,
   initiator in general can process those - except it should not in this case
of 'abort task set'.)

   OTOH, This approach breaks even for single connection sessions if status
recovery
   is eventually supported.  That makes me believe that this choice is an
optimization
   for a specific deployment scenario.  IMO, the draft would be generally
better off not
  describing specific scenarios.

Regards.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668
Roseville CA 95747

----- Original Message -----
From: "Somesh Gupta" <somesh_gupta@silverbacksystems.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>; <ips@ece.cmu.edu>
Sent: Friday, December 14, 2001 10:52 AM
Subject: RE: iSCSI: abort task & abort task set


> Julian,
>
> I like the proposal made at the IETF. I had two follow up questions
>
> 1. For targets that only support single connection per session, and do
> not support error recovery, would it be ok to send the status for the
> task management command without having to wait for the status ack
> for all previously sent statuses?
>
> 2. I have to analyze in more detail, but there is an interesting case
> where let us say that the status sent prior to the
> task management status suffers from a digest error, or a connection
> failure. The initiator retries the command on another connection. I
> have not fully figured out the implications of this.
>
> Somesh
>   -----Original Message-----
>   From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Julian Satran
>   Sent: Monday, December 03, 2001 10:51 PM
>   To: ips@ece.cmu.edu
>   Subject: Re: iSCSI: abort task & abort task set
>
>
>
>   Dear all,
>
>   On a phone conversation we have agreed to change the required behaviour
> along those lines enabling the initiator to drop all
>   outstanding commands after a response from a the task management
> abort/clear-task-set is received.
>   The iSCSI target will carry the burden for waiting for all outstanding
> statuses on all connections to be acknowledged after receiving the abort
> confirmation from the SCSI target and sending all statuses before returning
> the task management response.
>
>   Julo
>
>
>        "Mallikarjun C." <cbm@rose.hp.com>
>         Sent by: owner-ips@ece.cmu.edu
>         12-03-01 07:53 PM
>         Please respond to cbm
>
>
>                 To:        ips@ece.cmu.edu
>                 cc:
>                 Subject:        Re: iSCSI: abort task & abort task set
>
>
>
>
>   Resolution of this certainly requires an offline discussion -
>   which we two plan to have.  But one comment to make my proposal
>   clear to the list.
>
>   > I propose that the target deliver only the TMF response on an abort of
>   > an active task on an 'abort task' TMF, and not transmit an 'abort task
>   > set'
>   > TMF response until all the current StatSN's on all connections (as on
>   > the
>   > completion of "abort task set') in the session are ack'ed.  This ack
>   > may be
>   > solicited by way of a NOP-IN with valid TTT.
>   >
>   > +++ that may result in an initiator reusing prematurely an ITT and
>   > being hit by a late arriving status
>   > for a "former" task - i.e. non-deterministic behavior +++
>
>   That is not possible since as I said above, the 'abort task set'
>   TMF response is sent only after all StatSN "snapshots" are ack'ed
>   on all connections.
>   --
>   Mallikarjun
>
>   Mallikarjun Chadalapaka
>   Networked Storage Architecture
>   Network Storage Solutions Organization
>   Hewlett-Packard MS 5668
>   Roseville CA 95747
>
>
>   Julian Satran wrote:
>   >
>   > Mallikarjun,
>   >
>   > Comments in text - Julo
>   >
>   > PS - I would like also to point out that we may want to consider a
>   > very simple alternative to the barrier scheme outlined in 9.4
>   > - that will require less cooperation between initiator and will be
>   > simpler to read and implement.
>   > I will outline such a scheme soon.
>   >
>   >   "Mallikarjun C."
>   >   <cbm@rose.hp.com>                       To:        "ips"
>   >   Sent by: owner-ips@ece.cmu.edu  <ips@ece.cmu.edu>
>   >                                           cc:
>   >   12/03/2001 01:33 AM                     Subject:        iSCSI:
>   >                                   abort task & abort task set
>   >
>   >
>   >
>   > Julian,
>   >
>   > iSCSI currently requires two responses to be returned for an aborted
>   > task -
>   > one for the original task with a "good" status, and the second for the
>   > task
>   > management function (TMF) itself.  So, the following legal behaviors
>   > are
>   > required of a target -
>   >    a) plug the CmdSN gap if the command was not received,
>   >    b) send a SCSI response and TMF response if the task still is
>   > active,
>   >    c) send a TMF response if the task isn't active (if already
>   > complete).
>   >
>   > I would like to suggest that we reconsider our approach for case (b)
>   > for
>   > a variety of reasons, to change it to:
>   >    b) send a TMF response signalling that the abort is complete, if
>   > the
>   > task
>   >        still is active.
>   >
>   > Here are my reasons -
>   >
>   >    1. Target iSCSI layer would need to make a SCSI response up on
>   >        an abort of an active task.  It then follows that the iSCSI
>   > layer
>   >        may have to make up several SCSI responses on an 'abort task
>   > set'.
>   >
>   >   2.  The current approach also creates a side effect that isn't
>   > readily
>   >        apparent for 'abort task set'.  Initiators would need to stall
>   > processing
>   >        'abort task set' TMF response till task responses (to account
>   > for
>   > all
>   >        the tasks in the task set) on multiple TCP connections
>   > (possibly on
>   >        different NICs) are received - which I am afraid would
>   > tantamount to
>   >        an initiator scoreboard.
>   > +++ That is not entirely correct. The whole purpose of requiring the
>   > target to send a "good status" is to allow the initiator to send the
>   > response immediately and have the initiator mark its internal data
>   > structures as aborted - but avoid reusing ITT untill it gets the good
>   > answer.
>   > This way initiator can make progress and it can be sure that it won't
>   > be surprised by an "old" answer after it has reused the ITT
>   > +++
>   >    3. The current approach complicates initiator implementations that
>   > want
>   >        to process a successful SCSI completion even after they
>   > initiated
>   >        timeout processing since on an 'abort task set', initiators can
>   > never
>   >        be sure if the response was pre-abort, or post-abort (made up
>   > "good"
>   >        status).  I believe it is worth preserving this implementation
>   > choice.
>   > +++ see above +++
>   >   4.  I am further concerned that iSCSI is possibly in violation of
>   > the
>   > spirit of
>   >        SAM-2, rev20.
>   >         - clause 5.6.2 that states -
>   > "When an initiator causes its own task(s) to be aborted, no
>   > notification
>   > that the task(s) have been aborted shall be
>   > returned to the initiator other than the completion response for the
>   > command
>   > or task management function action
>   > that caused the task(s) to be aborted and notification(s) associated
>   > with
>   > related effects of the action (e.g., a target
>   > reset unit attention condition)."
>   > +++ I did say explicitly that the good status is a "good-will" message
>   > between iSCSI target and initiator. It does not have to reach SCSI.
>   > SAM also allows statuses that have been sent before an abort was
>   > executed but received after the TM response to be delivered or not at
>   > initiators will +++
>   >         - clause 5.3.1 that states -
>   > "GOOD. This status indicates that the device server has successfully
>   > completed the task."
>   >
>   > I propose that the target deliver only the TMF response on an abort of
>   > an active task on an 'abort task' TMF, and not transmit an 'abort task
>   > set'
>   > TMF response until all the current StatSN's on all connections (as on
>   > the
>   > completion of "abort task set') in the session are ack'ed.  This ack
>   > may be
>   > solicited by way of a NOP-IN with valid TTT.
>   >
>   > +++ that may result in an initiator reusing prematurely an ITT and
>   > being hit by a late arriving status
>   > for a "former" task - i.e. non-deterministic behavior +++
>   >
>   > This gives the determinism to initiators that  (a) abort task set TMF
>   > response
>   > signifies that the entire task set had been dealt with, and (b) every
>   > task
>   > response
>   > is a true SCSI end-to-end reponse (not generated by iSCSI), besides
>   > doing
>   > away with SCSI-response code in the target iSCSI layer.
>   >
>   > Comments?  Did I miss any corner cases?
>   >
>   > +++ see above +++
>   >
>   > Regards.
>   > --
>   > Mallikarjun
>   >
>   > Mallikarjun Chadalapaka
>   > Networked Storage Architecture
>   > Network Storage Solutions Organization
>   > Hewlett-Packard MS 5668
>   > Roseville CA 95747
>
>
>
>