Subject: RE: [Ips] Receiving a SCSI response after abort task was sent

From: "Robert Snively" <[email-masked]>
Date: Mon, 3 Jul 2006 10:18:27 -0700

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

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 03, 2006 6:54 AM
To: [email-masked]; [email-masked]
Subject: RE: [Ips] Receiving a SCSI response after abort task was sent

Erez,
 
> I have a question about aborting tasks: when an initiator sends "abort
task" to the target,
> it is possible that the target will send a SCSI response for the same
task before receiving the
> abort task (I guess that the target won't send a task management
response for the abort task).
 
Yes and (No) in that order.  The "abort task" task management function
is defined to succeed when the task does not exist - the response will
indicate success in this situation.
 
> What should the initiator do with the SCSI response?
 
Process it normally, as it would any other SCSI Response.
 
> 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.
 
Thanks,
--David
---------------------------------------------------- 
David L. Black, Senior Technologist 
EMC Corporation, 176 South St., Hopkinton, MA  01748 
+1 (508) 293-7953             FAX: +1 (508) 293-7786 
[email-masked]        Mobile: +1 (978) 394-7754 
---------------------------------------------------- 

________________________________

	From: Erez Zilber [mailto:[email-masked]] 
	Sent: Sunday, July 02, 2006 6:48 AM
	To: [email-masked]
	Subject: [Ips] Receiving a SCSI response after abort task was
sent

	Hi,
	
	I have a question about aborting tasks: when an initiator sends
"abort task" to the target, it is possible that the target will send a
SCSI response for the same task before receiving the abort task (I guess
that the target won't send a task management response for the abort
task). What should the initiator do with the SCSI response? 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?
	
	This message was also sent to linux-scsi mailing list.
	
	Thanks
	
	-- 

	____________________________________________________________

	Erez Zilber   |  972-9-971-7689

	Software Engineer, Storage Team

	Voltaire - The Grid Backbone

	 www.voltaire.com <http://www.voltaire.com/> 

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

---

From: William Studenmund <[email-masked]>
Date: Wed, 5 Jul 2006 10:47:34 -0700

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

> > Is it willing to receive only a task management response for the  
> abort task?
>
> 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

---

From: "Eddy Quicksall" <[email-masked]>
Date: Sun, 9 Jul 2006 13:35:42 -0400

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-masked] ; [email-masked] 
  Sent: Wednesday, July 05, 2006 1:47 PM
  Subject: Re: [Ips] Receiving a SCSI response after abort task was sent

    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?

    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

------------------------------------------------------------------------------

---

From: Julian Satran <[email-masked]>
Date: Mon, 10 Jul 2006 12:19:18 -0400

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-masked]> 
09/07/06 13:35

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

 
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-masked] ; [email-masked] 
Sent: Wednesday, July 05, 2006 1:47 PM
Subject: Re: [Ips] Receiving a SCSI response after abort task was sent

 

response for that task?
task?

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.

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

Take care,

Bill