RE: StatSN and overlapped commands

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

Pat,

Require to do checking or not (how and if this is done is mostly an 
implementation issue). If the target has decided to accept  recovery (and 
there no equivalent of it in the FCP world) it better protect it's ITTs. 
Obviously some implementations may be more sensitive to errors than others 
and those will check.

iSCSI already has an error code for this type of error - as we assumed 
that this might happen and it would be more difficult for some targets to 
live with the consequences of not checking.

If you consider this as a mandatory part of the compliance package or not 
is a question for the buyer to decide. I assume that the UNH package will 
(today or at some point in the future) check if this error code is 
generated properly and note it in the compliance sheets.

As for your assumption that you might keep lingering only the Status of 
the gone task - I already stated that this is not the case. If you accept 
recovery you must keep around enough information to recover anything not 
properly acked (and for some recovery level might end-up being asked to 
reinstate the task on another connection).

Julo



pat_thaler@agilent.com 
Sent by: owner-ips@ece.cmu.edu
08/08/2003 01:40

To
Julian Satran/Haifa/IBM@IBMIL, pat_thaler@agilent.com
cc
Black_David@emc.com, dcuddihy@attotech.com, ips@ece.cmu.edu, 
julian@cs.haifa.ac.il, owner-ips@ece.cmu.edu, satran@haifasphere.co.il
Subject
RE: StatSN and overlapped commands






Julian,

I have done some checking. Even for tasks that are in progress, neither 
the SCSI Architecture model nor iSCSI have any requirement that the target 
check that task tags from the initiator are unique. It is up to the 
initiator to ensure that the task tag is unique within the nexus. In the 
Fibre Channel world, FCP actually has an explicit statement that the 
target can rely on them being unique and isn't required to check for 
overlap.

It isn't the target's job to keep the initiator from messing up its use of 
task tags. If an initiator isn't using tags properly, there are plenty of 
other mistakes it can make that will cause problems and that the target 
can't detect.

Of course, as Bill and others have said, a target may check ITTs for 
overlap even though it isn't required to.

Pat

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 06, 2003 1:26 PM
To: pat_thaler@agilent.com
Cc: Black_David@emc.com; dcuddihy@attotech.com; ips@ece.cmu.edu;
julian@cs.haifa.ac.il; owner-ips@ece.cmu.edu; satran@haifasphere.co.il
Subject: RE: StatSN and overlapped commands


Pat,

If Status (if required) has to be sent with an associated ITT (it is the 
only way an initiator has to associate a status with a task). If the ITT 
happens to be that of a new task this association may be incorrect. Recall 

that error scenarios can be complex (with some missing statuses and even 
connection failover). 
For all those reason a target accepting recovery must "protect" any ITT 
included in unacknowledged status.

End-of-thread.
Julo



pat_thaler@agilent.com 
Sent by: owner-ips@ece.cmu.edu
06/08/2003 21:02

To
satran@haifasphere.co.il
cc
julian@cs.haifa.ac.il, Black_David@emc.com, dcuddihy@attotech.com, 
ips@ece.cmu.edu
Subject
RE: StatSN and overlapped commands






Julian,

For recovery, the target has to remember the status, but that doesn't mean 

it has to keep the task information around. It would have the status 
message linked to StatSN but it would be typical to clear away any task 
context when that message is generated. Remember that when things are very 

busy it might get a single acknowledgement that acknowledges multiple 
status messages from multiple tasks. It isn't efficient to have to go back 

to do the task context clean up when the status ack comes. 

It is the initiator's job to not shoot itself in the foot by issuing a new 

command with the same task tag as one that it hasn't gotten status on yet. 

For the target, once the status is generated, the task is gone. The status 

message may still be there available for a resend, but the task is gone. I 

don't see any requirement in iSCSI or SCSI to do anything other than that.

Regards, 
Pat

-----Original Message-----
From: Julian Satran [mailto:satran@haifasphere.co.il]
Sent: Tuesday, August 05, 2003 8:48 PM
To: THALER,PAT (A-Roseville,ex1)
Cc: julian@cs.haifa.ac.il; Black_David@emc.com; dcuddihy@attotech.com;
ips@ece.cmu.edu
Subject: Re: StatSN and overlapped commands


pat_thaler@agilent.com wrote:

> Julian,
> 
> I agree that the initiator is misbehaving, but I don't agree that the 
target should detect that misbehavior. The target SCSI layer thinks the 
command was done when it generated the status. As David said, the target 
keeps the status around so that it can resend it if requested by Status 
SNACK. It doesn't need to keep track of the tag anymore at that point.
> 
> If the target had to generate an error when a command came with for a 
tag before the status for a prior command with the same tag was 
acknowledged, then it would have to clear the memory of tags when status 
acks came in which is less efficient than doing it when posting the 
status.
> 
> Pat
> 
> -----Original Message-----
> From: Julian Satran [mailto:julian@cs.haifa.ac.il]
> Sent: Tuesday, August 05, 2003 10:56 AM
> <snip>
> 
>>
>>No, iSCSI at the target is retaining the SCSI status of the completed
>>command for retransmission.  SCSI believes the command to be completed,
>>and any retransmission request (e.g., Status SNACK) is not visible to
>>SCSI at the target.  In this case "command recovery" does not execute
>>any commands at the target; it just causes retransmission of the saved
>>status.
>>
>>Thanks,
>>--David
>>----------------------------------------------------
>>David L. Black, Senior Technologist
>>EMC Corporation, 176 South St., Hopkinton, MA  01748
>>+1 (508) 293-7953             FAX: +1 (508) 293-7786
>>black_david@emc.com        Mobile: +1 (978) 394-7754
>>----------------------------------------------------
>>
> 
> My only caveat to this would be that an initiator that reuses the 
> Initiator Task Tag but does not acknowledge the reception of the status 
> by an ExpSataSN is definitely misbehaving.
> 
> The target should not consider it as an implicit ack (as intermetiate 
> status PDUs may have been lost - it should reject the command that 
> reuses the Initiator Task Tag.
> 
> That is not necesarily related to the way an initiator maps SCSI tags to 


> iSCSI tags - it is specific to iSCSI expectations about tag reuse.
> 
> You correctly stated that an iSCSI tag should not be reused before it's 
> status is acknowledged but violating this rule is an iSCSI protocol 
> error and not a SCSI error (overlapped command).
> 
> Julo
> 
Pat,

The target has to remember the status the status for recovery - if both 
I and T have agreed on recovery. If it drops it some recovery scenarios 
won't work.

You are right that when no recovery is agreed status can be dropped but 
not so if recovery is agreed. And while within connection recovery is 
not based on ITT a recovered status containing a wrong ITT is not a good 
idea!

Julo