RE: Receiving a SCSI response after abort task was sent

Eddy,
 
Julian has shown you one example.
 
A second example is in some Fibre Channel environments, where in-order
delivery is optional.  In those cases, the rules say that you shall not
re-use
the fully qualified exchange identifier until a timeout has passed that
guarantees
that all possible responses have either been discarded in the network or
received (and discarded) by the initiator.
 
Of course, any technology may have a target failure that generates a
response for a command that either no longer exists or has never
existed.
That should not confuse anyone and certainly should not bring down an
initiator.  Be forgiving, and accept the unexpected response and discard
it.
You may choose to post a notice to some upper programming level, but
the system should not crash or create operational problems for other
targets.
 
Bob

________________________________

From: Julian Satran [mailto:[email protected]] 
Sent: Monday, July 10, 2006 9:19 AM
To: Eddy Quicksall
Cc: [email protected]; [email protected]; Robert Snively; William
Studenmund
Subject: Re: [Ips] Receiving a SCSI response after abort task was sent



Eddy, 

I don't think was talking about iSCSI (where it should not happen). But
SCSI was defined for a variety of technologies some which do not have
ordered and reliable transport. If you take technologies that have a
"link-by-link" error recovery (such as PCI express) and include some
switches in the "pot" this may definitely happen. So it is wise to be
prepared for it. 

Regards, 
Julo 



"Eddy Quicksall" <[email protected]> 

09/07/06 13:35 

To
"William Studenmund" <[email protected]>, "Robert Snively"
<[email protected]> 
cc
[email protected], [email protected] 
Subject
Re: [Ips] Receiving a SCSI response after abort task was sent

	




Wasn't Bob talking about technologies other than iSCSI? 
  
Bob, are you sure? Do you have an example of such a technology? 
  
I would think it would be dangerous for a technology to allow a SCSI
response to be received after the TMF response has been received for the
same command. My reasoning is that once the initiator has received the
TMF response it can reuse the ITT. In that case if the SCSI response for
the aborted command comes after the TMF response for the same command
but a new command has already used the same ITT, then there would be no
way to determine that the response should be discarded. 
  
Eddy 
----- Original Message ----- 
From: William Studenmund <mailto:[email protected]>  
To: Robert Snively <mailto:[email protected]>  
Cc: [email protected] <mailto:[email protected]>  ; [email protected]
<mailto:[email protected]>  
Sent: Wednesday, July 05, 2006 1:47 PM 
Subject: Re: [Ips] Receiving a SCSI response after abort task was sent 

On Jul 3, 2006, at 10:18 AM, Robert Snively wrote: 

With one minor warning, I agree with David. 
  
Warning below: 

> Is the host that issued the abort task willing to receive a SCSI
response for that task? 
> Is it willing to receive only a task management response for the abort
task? 
  
Yes and No in that order, the SCSI response is possible and must be 
handled.  There will always be a task management response, independent 
of whether the SCSI response is issued.  One important rule is that 
the SCSI response cannot occur *after* the task management response. 
  
In some technologies and under some conditions, it is hypothetically
possible for a SCSI 
response to appear at an initiator after the task management response.
In such environments, this will 
be detected as a SCSI response for which there is no SCSI request and it
will be discarded. 
Since TCP/IP forces in-order behavior on the SCSI stream, and since the
abort task is 
normally sent through the same stream as the command, this normally may
be ignored 
by iSCSI. 

I don't think this is a concern, because the ABORT TASK MUST be on the
same connection (section 10.5.1, page 131 of RFC 3720) as the command in
question. Thus StatSN numbering for the two is in the same number space.
The SCSI response should have a lower StatSN than the TMF response as
StatSN is the only real way to determine what is "before" or "after",
and we are talking about the case where the task finished "before" the
abort. 

So as the initiator processes StatSN responses, it will see the SCSI
response "before" the TMF response. 

As long as any other iSCSI transport (other than TCP) retains StatSN,
this will work right. 

Take care, 

Bill 

________________________________

_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips______________________________
_________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips