Subject: iSCSI : Digest Error recovery causes data corruption

From: Pierre Labat <[email-masked]>
Date: Wed, 31 Jan 2001 10:19:17 -0800

Hello,

I would invite you to revisit the Mike Krause mail about
"iSCSI Data Integrity - Digests".

If Alternative 1 or 2 is adopted, when a digest error (CRC)
occurs, the segment could be discarded, and TCP will
retransmit. For software implementation with an hardware
assist to calculate the CRC, (same kind of the one that exists
now to calculate the checksum now), if a CRC error is detected
it could be assimilated as a checksum error.
Hence there is no need to overload the iSCSI protocol
to deal with digest errors, because the iSCSI layer could not
see them.

Why to do complicate when simple an efficient can be achieved?

Regards,

Pierre

---

From: Matt Wakeley <[email-masked]>
Date: Wed, 31 Jan 2001 11:00:19 -0800

At first glance, the idea is nice.

However, options 1 and 2 require changes to the implementation and API of TCP
to provide the framing.  As you (should) know, we are not allowed to change
TCP.  Another problem is that your proposal to drop segments that have digest
errors violates the network layering.  TCP will deliver the PDUs to iSCSI. 
iSCSI is the layer that checks the CRC.  When TCP delivers the data to iSCSI,
it has already acknowledged the segment, so it can't be discarded and
retransmitted.  There is no way for iSCSI to tell TCP to accept or drop a
segment.

[all of the above assumes existing TCP definition/implementation.  Anything is
possible if one is allowed to change things]

-Matt

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 31 Jan 2001 12:15:58 -0800

Pierre,

A digest error is not seen by TCP.  TCP knows nothing about the content of
the byte stream and depends only on the TCP 16-bit checksum.  As such, TCP
will not retransmit.  There are two aspects to the iSCSI transport layer
added to TCP.  It should allow a mechanism to deal with transport related
errors independent of SCSI and it allows multiple TCP connections to be
shared as a single connection.  As the client or initiator share a single
sequence count, the handshake and selective acknowledgement is effectively
independent of any connection.  With an assumption the server or target
response does not require strict ordering over multiple connections, each
server connection enjoys an independent sequence.  It should be through
these sequences digest or header errors are recovered.  The iSCSI header
should be seen separate from SCSI.  Presently this is not the case and the
cause of complexity in my opinion.

Doug