[e2e] Re: [Tsvwg] Really End-to-end or CRC vs everything else?

[Michael A. Ramalho]

Michael/Doug,

This may be obvious to you all ... in that case, I
apologize ... but if you exclude the "errored bit"
being in the CRC itself (which, since it is conveyed
in the same channel, is something to consider) ...
then the CRC-L will always catch individual bit
errors separated by L bits or less. Thus, if the
native word length of the "stuck bit" word is 32 or
less (for a CRC-32) ... the CRC will *always*
catch the stuck bit (again, assuming the CRC
is not corrupted).

I know of no other easily proven statement for
bit "stuckedness" for Alder (or even other statistical
or frequency based checking/detection algorithms).

And just yesterday I just asked this question
to Prof. Mike Bushnell at Rutgers University. He just
received a NSF grant for spectrally-based digital
testing techniques and would probably know
such proofs.

So ... especially for SCTP transporting 32 bit
word length data (or less) ... this is yet another
reason for going CRC-32. As an aside, CRC-32
would catch a very large percentage of stuck at
errors for larger word lengths as well (probably
well over 99%).

Michael Ramalho


At 05:41 PM 6/7/2001 -0700, Douglas Otis wrote:
>Michael,
>
>The stuck bit tests for the more elaborate two Fletcher-16 sums indicated
>that errors were undetected 1.3% of the time using disk files as test cases
>if a stuck memory bus bit affected only half of the packet.  This
>pathological failure indicates a low level of assurance that data has not
>been corrupted.  The same test using CRC never failed.  This exceeds the
>number of bits assured by CRC, but the random nature of CRC still provides
>n:2^32 protection.  I did not bother with a splice test as the headers
>within SCTP should provide this level of protection unless these segments
>are out of order within the packet.  I had no information on the nature of
>this type of error.
>
>Doug
>
>
> >    Thu, 07 Jun 2001 09:02:54 -0700
> >    "Matt Wakeley" <matt_wakeley at agilent.com>
> >
> >    Jonathan Stone wrote:
> >
> >    > But *why* is crc32 thought to be better than a 32-bit mod-2^32
> >    > checksum or a fletcher checksum with two 16-bit halves?
> >    > A citation would be wonderful.
> >
> >    try draft-sheinwald-iSCSI-CRC-00.txt  It has lots of citations in it.
> >
> > While it may (probably) be true that CRC32 performs better than Fletcher
> > and/or 32bit ones complement sum on real data, the draft-sheinwald-...txt
> > says "For real data ... checksums behave substantially worse than
> > CRCs" and
> > cites our paper in TON '98 [Stone98].  The results there,
> > however, compared
> > a *32bit* CRC against a *16bit* ones-complement sum and *16bit* Fletcher
> > (both one and twos complement).
> >
> > Also, the measurements in our paper were based on a very specific error
> > model: packet-splices.  Care must be exercised when generalizing those
> > measurements.
> >
> > I am not quibbling with the results quoted in the draft for the
> > burst-error
> > model over uniformly distributed data: the advantage of CRC32 there over
> > Fletcher (in terms of error-rate and size of protected block) is
> > compelling.  And, given the factor of 10^4 advantage, CRC32 is probably
> > *still* the way to go.  However, as pointed out by our TON paper, this
> > should not make us complacent.  In the real world it is possible for
> > pathological distributions of data to be common, and combined with a
> > particular error model the resulting protection offered by *any* checksum,
> > CRC, or what-have-you may be *much* weaker than the theoretical model.
> >
> >
> > _______________________________________________
> > tsvwg mailing list
> > tsvwg at ietf.org
> > http://www1.ietf.org/mailman/listinfo/tsvwg
> >
>
>
>_______________________________________________
>tsvwg mailing list
>tsvwg at ietf.org
>http://www1.ietf.org/mailman/listinfo/tsvwg


Michael A. Ramalho, Ph.D.
Office email: mramalho at cisco.com
Personal email: mar42 at cornell.edu
Office: +1.732.449.5762
Cell: +1.732.809.0188