Subject: [Tsvwg] checksum CRC reference

From: Lyndon Ong <[email-masked]>
Date: Mon, 14 May 2001 20:08:14 -0700

Folks,

For reference, David Black has passed a pointer to 
http://ietf.org/internet-drafts/draft-sheinwald-iscsi-crc-00.txt for a good 
discussion of CRC codes and their characteristics.

I have to say, Doug's results were quite confusing, esp. where the Adler-32 
seemed to be performing much better than modified Adler.  I did note that 
CRC seemed to perform best...

Cheers,

L. Ong

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Douglas Otis" <[email-masked]>
Date: Mon, 14 May 2001 22:00:48 -0700

Lyndon,

I don't think it is all that hard to understand.  The modified Adler used a
straight 16 bit adder for s1 that works at the same modulo as a hardware
failure.  A matching binary modulo make it less successful at detecting such
a failure.  The Adler-32 breaks the pattern into single byte adds with two
Adler modulo.  The disadvantage of adding at the byte level is greater
sensitivity to burst errors of which I was not testing.  To use a modulo on
both summations for the modified Adler would create a blind code.  It is not
an easy problem to solve.

Doug

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 15 May 2001 15:18:24 -0500

Lyndon,

I think the checksum/CRC discussion is suffocating from too much
information :-) IMO, what we desperately need now is some selection
criteria (something like a requirement statement/document).

Seemingly, nobody likes option/negotiation-based solutions. So we must
make a selection.

We know now that there are multiple checksum-based and CRC-based
solutions to choose from.

We know now that the implementation cost of each of the candidates
varies widely and depends on different factors (e.g., 32bit-machine vs.
64bit-machine, software vs. hardware, big cache vs. small cache, etc).

We know now that there are many different error models that can be used
to evaluate the effectiveness of the candidates.

We know now that none of the candidates is the clear winner in all the
error-scenarios (the only thing seems sure is that CRC-based ones
perform better than the sum-based ones).

We know now that different application areas are looking for different
level of transport data integrity checking.

Whichever direction we take, we must keep in mind that SCTP is a general
purpose transport and our final decision should be balanced and should
not be biased towards any specific group of applications or platforms.

regards,
-Qiaobing

---

From: "Randall R. Stewart" <[email-masked]>
Date: Tue, 15 May 2001 20:26:26 -0500

Q:

I concur completely... We need a general even puposed solution
that can be put in big and small devices and is general enough
for all applications...

R

-- 
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222 (cell) 815-477-2127 (work)