Re: 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 
To: Robert Snively 
Cc: [email protected] ; [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