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

From: [email-masked]
Date: Tue, 11 Nov 2003 09:44:24 -0500

I think that resetting the connection is the only solution that will always
work and will not lead to interoperability problems.  It is already
specified in sections 3.2.5, and 6.12.

Using the combination of bad data and a bad data digest is not equivalent
to a reset.  You must go through the options in section 6.7 in this case.
The connection could still be reset depending on the error recovery level,
number of connections, and the iSCSI implementation anyways.

What would be the benefit of using the bad digest over reset?  If an
implementation is incorrect, for example it pads the data but data digest
is off, it will be hard to debug or test the flaw and products might get
out the door with data integrity problems.

Also, digest errors should be rare, the overuse of this type of trick in
TCP stacks diminished the usefulness of the TCP checksum.  Which is why we
have digests in the first place.

Aaron

                    wrstuden@wasabis                                                                           
                    ystems.com             To:     [email-masked]                                      
                    Sent by:               cc:     [email-masked], [email-masked]                               
                    [email-masked]       Subject:     RE: [Ips] Handling error during packet transmission    
                    rg                                                                                         

                    11/10/2003 11:58                                                                           
                    AM                                                                                         

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

_______________________________________________
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: [email-masked]
Date: Tue, 11 Nov 2003 12:04:05 -0800 (PST)

> specified in sections 3.2.5, and 6.12.

3.2.5 certainly leaves the big hammer as an option.

However I'm not sure if 6.12 really applies here. The TCP connection is
fine, it's the data that are in it that are the problem.

> out the door with data integrity problems.

As a result of this discussion, I think that sending pad data w/o digests
is wrong.

Why a bad digest? Because it's less intrusive in theory. Having to use the
"big hammer" means that an error with one PDU (which really would mean
killing one task) turns into an error on all tasks on that connection.
Since you need multiple commands outstanding at once to get line rate
(otherwise you see round-trip latency issues), you will most likely have
other commands arround to feel the pain of the big hammer.

I admit though that chances are initial products will just use the big
hammer.

> have digests in the first place.

Huh?

The reason we have digests is that the TCP checksum is insensitive to too
many multi-bit error patterns. Since it's a sum, if you have a set of bit
errors that sum to zero (0->1 transition == + whatever, 1->0 transition ==
- whatever), you will get the same TCP checksum. Your data are wrong, but
the checksum is fine.

That's why we have digests.

Take care,

Bill

---

From: Paul Koning <[email-masked]>
Date: Tue, 11 Nov 2003 16:29:09 -0500

>>>>> "wrstuden" == wrstuden  <[email-masked]> writes:

 wrstuden> Why a bad digest? Because it's less intrusive in
 wrstuden> theory. Having to use the "big hammer" means that an error
 wrstuden> with one PDU (which really would mean killing one task)
 wrstuden> turns into an error on all tasks on that connection. ...

Doesn't matter.  Optimizing error handling is rarely useful -- only if
you have a significant error rate.

If the sort of problem we were talking about occurs multiple times per
day, you should repair the broken hardware.  The performance impact of
the recovery for that case is quite uninteresting by comparison.

    paul