RE: [Tsvwg] [SCTP checksum problems]

["Douglas Otis" <dotis@sanlight.net>]

Qiaobing,

In essence, the problems for iSCSI and SCTP are similar.  Both wish to
improve error detection over TCP checksums.  Examination of Adler-32
indicated weak burst error detection and low sensitivity for small frames, a
principle uses of SCTP at this point.  A realistic means of examining the
transport end-to-end error detection is needed for both of these protocols,
although SCTP is indeed more generalized.  Moving forward, it would be
beneficial if a common scheme were employed and agreed adequate.  There are
problems with various Telco components over more robust Ethernet equipment.
DSLAM interfaces and poorly aggregated SONET packets may be areas of greater
concern than Gaussian noise or burst errors.  Without a better understanding
of the present error sources, assessing any scheme is difficult.

A 128k byte table for CRC is not practical for most applications so CRC
requires about 8 instructions per byte with a 1K lookup table.  The modified
Adler-32 where S1 becomes a simple unsigned summation of 16 bit values
seeded with 0x5555 but where S2 retains the Adler modulo only requires about
2 instructions per byte versus about 3 of the prior algorithm.  This
modification reduces the present overhead depending the host to network
endian arrangement and should help with both burst error detection and
smaller packets.  This modification would also reduce the overhead
associated with a hardware implementation of this scheme.

Those working with storage products are expert at assessing burst error
detection and it is not likely any other scheme other than CRC will provide
superior fault coverage for burst errors.  This assessment is not likely
realistic if burst errors or Gaussian noise are not a predominate source.
Virtually any error scheme done in addition to the IEEE CRC found on the
various physical serial transports will provide adequate coverage.  The
problems arise from errors outside this CRC protective blanket.  The
assessment may concern the bit distribution of algorithms and susceptibility
to various pathological patterns.  Again, CRC hold advantages in this area
but it may also become a weakness with respect to some error modes where bit
coloring can be advantageous.

This area is not easily resolved because of the many facets involved.  It
would appear with the problems uncovered with Adler-32, this work should be
revisited and hopefully put to rest.

Doug

> Hi, all,
>
> Please correct me if I am under the wrong impression, but what I've been
> hearing so far from the discussion in this thread seems to be:
>
>  1) There is uncertainty on what error model should be used for
>     evaluating transport error check mechanisms;
>
>  2) iSCSI level integrity/authentication seems inevitable not matter how
>     strong the transport error check is;
>
>  3) Some uncertainty about the implementation cost (hw and sw) on some
>     of the proposed CRC-based schemes, but almost certainly any
>     CRC-based scheme will be more expensive than checksum schemes;
>
>  4) Discussion of requirements has been so far very much limited to
>     iSCSI data transport, and it seems that a CRC-based scheme is
>     strongly desirable for iSCSI case _if_ the transport error check
>     alone is all we will get to meet the iSCSi requirements.
>
> Now my question to the group is: if a weaker but much cheaper SCTP error
> checking mechanism can be found to be sufficient to the majority of the
> applications (remember SCTP is a general purpose transport), and the
> ultra-low error rate applications such as iSCSI will eventually rely on
> their own integrity check, should we adopt a selection approach which
> put more emphasis on the ease-of-implementation side?
>
> (Maybe after all the Adler-32 in the current RFC2960 is good enough :-)
> )
>
> regards,
> -Qiaobing