Subject: [Ips] iSCSI: question regarding ABORT TASK SET + ABORT TASK interaction

From: "Buck Landry" <[email-masked]>
Date: Thu, 13 May 2004 14:51:49 -0500

An example scenario:

I->T Scsi Command (CmdSN=0x1, ITT=0x1, LUN=0, WRITE_10)
T->I R2T (ITT=0x1, TTT=0x1, ExpCmdSN=0x2, MaxCmdSN=0x10)
I->T Task Mgmt Request (ABORT TASK SET, CmdSN=0x2, LUN=0, I=0)

/* .. target waits for TTT 0x1 to be satisfied as described in RFC 3720, 10.6.2.. */

I->T Task Mgmt Request (ABORT TASK, CmdSN=0x3, LUN=0, I=1, RefCmdSN=0x1, RefTaskTag=0x1)

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

When the ABORT TASK arrives, is the WRITE_10 still considered a "valid task" as mentioned in 10.6.1 ("a)  If the Referenced Task Tag identifies a valid task...") ?

If so, I assume the WRITE_10 is aborted by the ABORT TASK, the ABORT TASK rsp ("function complete") is issued, and the ABORT TASK SET rsp is also issued.

If not, I assume 10.6.1 "c)  If the Referenced Task Tag does not identify an existing task..." applies; an ABORT TASK rsp ("task does not exist") is issued, and the ABORT TASK SET continues waiting for the R2T's TTT to be responded to.

.. As a 3rd possibility, perhaps an initiator is forbidden from sending such a sequence of PDUs -- it certainly doesn't seem like a good idea.  But I'm not sure the RFC forbids it.  10.5.1 "For ABORT TASK SET and CLEAR TASK SET, the issuing initiator MUST continue to respond to all valid target transfer tags" comes close, but I don't see that as excluding any other PDUs (such as an immediate ABORT TASK) the initiator might also wish to send.

I'm looking at this from the perspective of a target implementer who's trying to "do the right thing".  Any insights would be appreciated.  Thanks,

--buck

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

---

From: Julian Satran <[email-masked]>
Date: Thu, 13 May 2004 19:51:16 -0700

[email-masked] wrote on 13/05/2004 12:51:49:

> When the ABORT TASK arrives, is the WRITE_10 still considered a 
> "valid task" as mentioned in 10.6.1 ("a)  If the Referenced Task Tag
> identifies a valid task...") ?
>

The task is still valid (waiting for Data)
 
> If so, I assume the WRITE_10 is aborted by the ABORT TASK, the ABORT
> TASK rsp ("function complete") is issued, and the ABORT TASK SET rsp
> is also issued.
> 

Correct.

> If not, I assume 10.6.1 "c)  If the Referenced Task Tag does not 
> identify an existing task..." applies; an ABORT TASK rsp ("task does
> not exist") is issued, and the ABORT TASK SET continues waiting for 
> the R2T's TTT to be responded to.
> 
> .. As a 3rd possibility, perhaps an initiator is forbidden from 
> sending such a sequence of PDUs -- it certainly doesn't seem like a 
> good idea.  But I'm not sure the RFC forbids it.  10.5.1 "For ABORT 
> TASK SET and CLEAR TASK SET, the issuing initiator MUST continue to 
> respond to all valid target transfer tags" comes close, but I don't 
> see that as excluding any other PDUs (such as an immediate ABORT 
> TASK) the initiator might also wish to send.
> 
> I'm looking at this from the perspective of a target implementer 
> who's trying to "do the right thing".  Any insights would be 
> appreciated.  Thanks,
> 
> --buck
>