Re: aborting an out of sequence cmdSN

[Santosh Rao <santoshr@cup.hp.com>]

Julian,

I understand that nothing in the current draft prevents usage of
connection allegiance for an abort task to flush the stale PDUs of a
command. 

However, as a target implementor, if such a guaranteed mechanism is not
mandated to flush stale PDUs of a command, targets will need to build
safeguards against possible stale PDUs from a command. Any such scheme
would cause targets to retire resources until a safe period (based on a
best guess !) has elapsed. The targets CANNOT depend on initiators
deploying this scheme in the absence of the spec mandating this and do
not have a guarantee that stale PDUs will not arrive after the Abort
Task has cleaned up the command at the target end.

Keeping in mind the above, I am asking that iSCSI mandate that the Abort
Task be sent on the same connection as the SCSI command being aborted.
In addition, [and this has been asked earlier], the iSCSI draft lacks a
section on I/O timeout handling under the error recovery section. Some
description must be provided on the actions an initiator should take on
an I/O timeout. (or timeout of other iSCSI PDUs).

For instance, should non-SCSI PDUs be timed ? (login, text, etc). If so,
what is their timeout values. What actions should an initiator take if
they time out. How is the task tag for that non-SCSI PDU cleaned up,
ensuring no stale PDUs are going to arrive for that task tag.

iSCSI Error Recovery descriptions MUST address task timeout handling. 

- Santosh


julian_satran@il.ibm.com wrote:
> 
> First the current draft does not stop you from doing what you want - it
> just does not mandate it.
> Second with CmdSN now you have a better chance - before handing the command
> over to SCSI task management
> mark all the relevant commands in the iSCSI queue as non-deliverable to a
> LUN or all LUNs or keep a stack of barriers for active aborts (I assume
> that this is a reasonably low number) to the same effect.
> 
> Julo
> 
> Santosh Rao <santoshr@cup.hp.com> on 18/04/2001 01:10:17
> 
> Please respond to Santosh Rao <santoshr@cup.hp.com>
> 
> To:   Sandeep Joshi <sandeepj@research.bell-labs.com>
> cc:   ips@ece.cmu.edu
> Subject:  Re: aborting an out of sequence cmdSN
> 
> I'd think option 1 is the simplest (with the caveat that the task mgmt
> PDU referred to is the Abort Task.) and only impacts the affected
> command/task.
> 
> Pierre Labat and I have asked for this 4 months ago. (See :
> http://ips.pdl.cs.cmu.edu/mail/msg02958.html). The concept of connection
> allegiance should be extended to include the Abort Task. Also,
> connection allegiance should apply to the task (which spans multiple
> commands in the case of linked commands.), allowing for a deterministic
> clean up of stale PDUs of the task through the use of Abort Task.
> 
> - Santosh
> 
> Sandeep Joshi wrote:
> 
> >
> > So our options for abort_task boil down to..
> > (1) use connection allegiance for TASK MGMT PDU.
> > (2) reject all commands prior to cmdSN of TASK MGMT PDU.
> > (3) cmdSN of original task is sent with TASK MGMT PDU and
> >     target at the iSCSI layer keeps state.
> > (4) iSCSI initiator retains state for deleted tasks to ensure
> >     that R2T/Scsi Responses are appropriately handled.
>  - santoshr.vcf
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard