RE: StatSN and overlapped commands

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

That is definitely correct. - Julo



<pat_thaler@agilent.com> 
Sent by: owner-ips@ece.cmu.edu
07/08/2003 22:15

To
<wrstuden@wasabisystems.com>, <pkoning@equallogic.com>
cc
<eddy_quicksall@ivivity.com>, <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






I agree with that approach as well. 

It is valid for the target to still have the ITT in use until it gets the 
status acknoledgement. For instance, the target may need to do this when 
it supports data retransmission and there is still unacknowledged data for 
the command. If the initiator has a bug that causes it to duplicate ITT, 
the target MAY generate an error. It isn't necessary to call this case out 
explicitly.

Note that the initiator may reuse the ITT once the initiator has received 
the status. Therefore, a target might receive a PDU that has an ExpStatSN 
acknoledging receipt of a status message for a previous command where the 
new command has the same ITT as the previous command. If the target is 
checking for duplicate ITT, it must ensure that it clears away any ITTs 
for tasks acknowledged by the new PDU before it checks for duplicate ITT. 
This is just proper operation and I don't think we need to state this case 
explicitly either.

Pat

-----Original Message-----
From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com]
Sent: Wednesday, August 06, 2003 4:31 PM
To: Paul Koning
Cc: eddy_quicksall@ivivity.com; 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, Paul Koning wrote:

> Rather than clutter up the spec with more notes that say something is
> an error you can ignore, I'd rather keep it simple.
>
> I believe it's agreed that the case we're talking about is an
> initiator bug.
>
> Do we need to describe all possible bugs, and all allowed responses to
> such bugs?  I don't think so.  The spec should describe correct
> behavior, and required consistency checks.
>
> There's an infinite number of possible wrong behaviors that can be
> generated by bugs.  I believe this should just be covered by the
> standard *unwritten* rule that, if you mess up the protocol, you may
> not get the answer you were hoping for.

I'm happy with that too. My main concern, which you agree with, is to make
sure we don't say that this ITT re-use (w/o status ack) is something the
target MUST be happy with. Saying, "You get what you get," is fine.

Take care,

Bill