RE: StatSN and overlapped commands

["Ranganathan, Deva" <Deva_Ranganathan@adaptec.com>]

Thanks, Pat. Got it.

-Deva

-----Original Message-----
From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] 
Sent: Thursday, August 07, 2003 6:05 PM
To: Ranganathan, Deva; eddy_quicksall@ivivity.com; pat_thaler@agilent.com
Cc: ips@ece.cmu.edu
Subject: RE: StatSN and overlapped commands


Deva

"should not be required" is a statement about what the RFC should not do. It
doesn't mean the target should not generate the error. 

"The target should not be required to do x" is an entirely different
statement from "The target should not do x". The latter means that the
behavior should be discouraged. The former means that the standard should
not require the behavior - it can be left as an implementation decison. 

Pat

-----Original Message-----
From: Ranganathan, Deva [mailto:Deva_Ranganathan@adaptec.com]
Sent: Thursday, August 07, 2003 5:22 PM
To: 'Eddy Quicksall'; pat_thaler@agilent.com
Cc: ips@ece.cmu.edu
Subject: RE: StatSN and overlapped commands


>Yes, the target could give that response but it should not be required 
>to
check the ITT

I am disagreeing  to "SHOULD NOT" above. It is implementation specific. If
the initiator sends  a duplicate command, it is implementation what the
target does with the command with a duplicate ITT.  

-Deva

-----Original Message-----
From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] 
Sent: Thursday, August 07, 2003 5:11 PM
To: Ranganathan, Deva; pat_thaler@agilent.com
Cc: ips@ece.cmu.edu
Subject: RE: StatSN and overlapped commands


No one has suggested preventing a target from taking care of it.

Eddy

-----Original Message-----
From: Ranganathan, Deva [mailto:Deva_Ranganathan@adaptec.com] 
Sent: Thursday, August 07, 2003 8:07 PM
To: 'Eddy Quicksall'; pat_thaler@agilent.com
Cc: ips@ece.cmu.edu
Subject: RE: StatSN and overlapped commands

Since it is implementation specific, a target MAY take care of this scenario
by a suitable error response as defined in 
the current spec. If a target implementation can perform this, why prevent
it?  

Thanks

Deva


-----Original Message-----
From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] 
Sent: Thursday, August 07, 2003 4:50 PM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu
Subject: RE: StatSN and overlapped commands


I assume you mean 10.17.1. Yes, the target could give that response but it
should not be required to check the ITT. That is what I meant by "make it an
error". It could take time to do that and the target should not be in the
business of debugging the initiator.

That is what I meant by "make it an error".

I object to the target (or initiator) being required to do anything to cover
cases where the other side screwed up ... unless it could adversely effect
the target (or initiator) such as a crash. 

Eddy

-----Original Message-----
From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] 
Sent: Thursday, August 07, 2003 6:54 PM
To: wrstuden@wasabisystems.com; eddy_quicksall@ivivity.com
Cc: pat_thaler@agilent.com; satran@haifasphere.co.il; julian@cs.haifa.ac.il;
Black_David@emc.com; dcuddihy@attotech.com; ips@ece.cmu.edu
Subject: RE: StatSN and overlapped commands

Eddy,

I'm not sure what you mean by "make it an error". iSCSI already has an error
that covers this situation doesn't it? I'm looking at 10.7.1 on reason code
0x09. Note 2 says this includes invalid TTT/ITT.

Pat

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


On Wed, 6 Aug 2003, Eddy Quicksall wrote:

> I don't think we should make it an error if that implies that the 
> target needs to check for the error.

In my most recent note, I'm suggesting we make it an error, but that we let
the target ignore the "error" if it has already terminated the task.

If we don't make it an error, we run into the question of what should a
target do if the first (status-unacknowledged) task needs to support
recovery actions. If the second, same ITT, task is allowed to exist, Data
SNACKs become ambiguous. That strikes me as VERY much against the intent of
data recovery. :-) Just letting the target report this as an error seems the
easiest thing to do.

The reason for letting the target ignore this case is so that we permit
implementations like Pat was describing. If you know you aren't going to do
any recovery (either you aren't supporting it or it's a SCSI write command
and thus the target knows all is done), then it's fine to kill the task, and
then this case isn't ambiguous.

> It seems that if the initiator does this, he probably has a bug or a 
> race condition that will lead to a bug later. So isn't it his 
> responsibility to debug his program?

I agree it's the initiator's problem. The thing is that if we don't make it
an "error", then the target has to deal with the problem, and the corner
cases can get messy.

So to be clear, I'm suggesting the "it's an error you can ignore if it isn't
a problem" approach so that we give different target implementations the
room to deal with the situation as they see fit.

Take care,

Bill