Subject: RE: [Ips] Handling error during packet transmission

From: [email-masked]
Date: Fri, 7 Nov 2003 13:45:01 -0700

Mallikarjun,

Sending an unsucccessful status applies if it is a SCSI Read. What if it s a SCSI Write - that is, the initiator is sending the data? Can it solve the problem by aborting the task?

Regards,
Pat

-----Original Message-----
From: Mallikarjun C. [mailto:[email-masked]]
Sent: Friday, November 07, 2003 10:47 AM
To: [email-masked]; [email-masked]
Subject: Re: [Ips] Handling error during packet transmission

Bill,

I think you have all the different possible solutions identified.
My take is that the choice is one of implementation/solution
considerations - such as how fault-tolerant you want to be,
how many other I/Os are likely active on the connection at
any time, how expensive it is to recover the other I/Os if connection
is dropped, how flexible is your code, can the target fence
the malfunctioning physical memory and continue on or the
session has to be killed anyway...etc.

Given that the SCSI initiator cannot make any assumptions
about the contents of a posted Data-in buffer unless it receives
a successful completion from the target, the only spec requirement
in the scenario you describe is that the target must not send
a successful SCSI status.

Mallikarjun

At 04:21 PM 11/6/2003, [email-masked] wrote:
>Ok, here's an error that I admit is a bit extreme.
>
>What do you (a target or initiator) do if you have sent the header for a
>PDU and then realize, say due to ECC memory error detection, that you
>can't send the rest of the PDU?
>
>Say the target is servicing a SCSI READ command. It sets up a PDU for
>transmission. Assume we're on a link where we aren't sending jumbo grams
>and the PDU will mean multiple ethernet frames. Now say that there is a
>(detected) data corruption event during the transmission of the PDU. Like
>a double bit error on ECC system memory for instance. The point is the PDU
>header has gone out but we don't have all the data.
>
>And assume that when we go to try and recover the data, we find out we
>can't easily get it (it wasn't say a PCI transfer error that re-running
>the transfer will recover). We decide we don't want to stall the TCP
>connection getting it.
>
>What do we do?
>
>If we had data digests, one option would be to fill the rest of the
>PDU with nonsense (zeros?), and deliberately send a bad digest.
>
>If we didn't have digests, would it be reasonable to send garbage (zeros?)
>to fill the PDU, then abort the command with a CHECK CONDITION and
>indicate an underrun that didn't include the unsent PDU data?
>
>As an example, we successfully send 8K of data, then we are sending a
>DATA-IN PDU with 8k, and run into the error after 4k. We abort the
>command, and indicate that only 12k of data were sent. ?
>
>Yes, this shouldn't happen, but what do you do if it does?
>
>Take care,
>
>Bill
>
>_______________________________________________
>Ips mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ips

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

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

---

From: "Mallikarjun C." <[email-masked]>
Date: Fri, 07 Nov 2003 16:39:17 -0800

Pat,

I understood the question to be only about a SCSI Read,
but you're right, the other interesting case is of a non-recoverable
error happening on the initiator while servicing an R2T.  As
you suggest, an initiator-initiated abort TMF should ensure the
correctness and ordering expectations here.  Initiator must not
of course complete the Data-out sequence that took the hit (even
if it did, not with the "Desired Data Transfer Length" # of bytes).

Regards.
Mallikarjun

At 12:45 PM 11/7/2003, [email-masked] wrote:
>Mallikarjun,
>
>Sending an unsucccessful status applies if it is a SCSI Read. What if it s 
>a SCSI Write - that is, the initiator is sending the data? Can it solve 
>the problem by aborting the task?
>
>Regards,
>Pat
>

---

From: [email-masked]
Date: Mon, 10 Nov 2003 08:58:33 -0800 (PST)

On Fri, 7 Nov 2003 [email-masked] wrote:

> Mallikarjun,
>
> Sending an unsucccessful status applies if it is a SCSI Read. What if it
> s a SCSI Write - that is, the initiator is sending the data? Can it
> solve the problem by aborting the task?

I'd say that the right solution is, "The big hammer."  Just as SCSI READ
data can get copied into buffers, SCSI WRITE data can get copied into
buffers and cause confusion.

So I think the answer is that if you're using digests, pad the PDU and
send a bad digest. If you aren't, RST the connection. And even if you are
using digests, you can RST if you like.

Take care,

Bill