Subject: [Ips] Abort/error handling for task with pending data sequence

From: Jane Liu <[email-masked]>
Date: Wed, 18 Feb 2004 15:01:46 -0800

Hi,

What should the target do when it gets an Abort Task request for a SCSI
write command that has an unterminated data sequence? Is it safe to assume
that the initiator will not send any more data PDUs for the task to be
aborted? 

When the target detects a payload digest error on the command PDU for a SCSI
write command, what should it do if the offending PDU does not have the
F-bit set (unsolicited data PDUs are expected). Section 6.7 of the spec says
that the target must reject and discard the offending PDU, and "no further
action is necessary". Should the target do just that and then reject the
unsolicited data PDUs with "Invalid PDU Field"? 

Thanks in advance for all replies.

Jane Liu

---

From: Julian Satran <[email-masked]>
Date: Thu, 19 Feb 2004 14:39:50 +0200

Jane,

[email-masked] wrote on 19/02/2004 01:01:46:

> Hi, 
> What should the target do when it gets an Abort Task request for a 
> SCSI write command that has an unterminated data sequence? Is it safe 
> to assume that the initiator will not send any more data PDUs for the 
> task to be aborted? 

No it is not safe. The target should send it's response to TM only after 
receiving all the data (unsolicited and expected).
The data may be arriving on a different connection than the TM or may be 
generate by a different thread at the initiator (there is no guaranteed 
sequence).

> When the target detects a payload digest error on the command PDU for 
> a SCSI write command, what should it do if the offending PDU does not 
> have the F-bit set (unsolicited data PDUs are expected). Section 6.7 
> of the spec says that the target must reject and discard the offending
> PDU, and "no further action is necessary". Should the target do just 
> that and then reject the unsolicited data PDUs with "Invalid PDU Field"? 

The target may want to delay the reject until it gets all the data.
Otherwise if the initiator reuses the ITT some races may result.

> Thanks in advance for all replies. 

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

---

From: "Mallikarjun C." <[email-masked]>
Date: Fri, 20 Feb 2004 12:57:48 -0800

Jane,

I remember an earlier discussion on your first question,
I thought we had added a "SHOULD NOT" prohibition on the
initiator (don't send anymore data after issuing an abort),
but I can't find it now.  In any case, if your question
is about a single Abort Task TMF (not the task set, which
Julian may be referring to), I think it's fairly safe to
return the response to the TMF after doing the necessary
cleanup on the target.  The assumptions/rules are: a) initiator
sends the Abort Task TMF only on the allegiant connection,
or when there's no allegiant connection (section 10.5.1,
top of page 123), b) target discards the data-out PDUs on
that task, if any, with Rejects (required behavior per 10.17.1),
and (c) initiator will not blindly start retransmitting the
data PDUs on seeing the rejects (it should be really broken
to do that on an aborted task....).

On your second question: it's very close to the scenario
described in 10.17.1, bottom of page 168, but not quite
the same.  You're asking about a payload digest error
on the command PDU, so the task isn't even instantiated
(per section 6.3).  So I don't believe your scenario is
technically bound by the "MUST wait" rule in 10.17.1, but
it's still a good idea to do what Julian suggests to avoid
running into needless exception handling and Rejects down
the road.

Hope that helps.
-- 
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com