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

[Douglas Otis]

Craig,

Adding to that, if errors were only due to random noise, then a summation
would be okay.  If the errors are not random and are the result of a weak
bus driver as example, then these errors will find a considerable weakness
in a summation that has the same patterns as the errors.  Hardware related
errors may not be random in nature, so any assumption that errors are random
becomes incorrect in these cases.  The source of random errors on the serial
line is prevented by CRC, so remaining errors move more into the area of
hardware related.

Doug

> In message
> <4.3.2.7.2.20010608171151.0e9bfcf0 at mira-sjc5-9.cisco.com>, "Michael
> A. Ramalho" writes:
>
> >I know of no other easily proven statement for
> >bit "stuckedness" for Alder (or even other statistical
> >or frequency based checking/detection algorithms).
>
> The TCP checksum catches all error patterns that are 15-bits longer or
> less and all but one 16-bit long error.  If you did the TCP checksum as
> a 32-bit checksum (32-bit adds instead of 16) you'd have the same
> property.  If single bit errors are the error pattern, CRC is overkill.
>
> Key point here is we need an error model that is realistic to determine
> what checksum to use.
>
> [Side point -- Jonathan apologies if this steals your thunder -- but
> Jonathan has a nice little proof that, if all error patterns are equally
> likely, that a checksum that just includes a fixed size constant to each
> packet is just as effective as any stronger check -- the moral here is, if
> you don't know the error pattern, you don't know which checksum
> to choose].
>
> Craig
>
> _______________________________________________
> tsvwg mailing list
> tsvwg at ietf.org
> http://www1.ietf.org/mailman/listinfo/tsvwg
>