Subject: FW: I-D ACTION:draft-cavanna-iscsi-crc-vs-cksum-00.txt

From: "Matt Wakeley" <[email-masked]>
Date: Thu, 1 Mar 2001 12:57:11 -0800

FYI - We put this out quickly to beat the deadline - a better version will
be submitted before the final cut-off...

-Matt Wakeley
Agilent Technologies

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of [email-masked]
Sent: Thursday, March 01, 2001 4:21 AM
To: IETF-Announce:
Subject: I-D ACTION:draft-cavanna-iscsi-crc-vs-cksum-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: iSCSI Digests û CRC or Checksum?
	Author(s)	: V. Cavanna, M. Wakeley
	Filename	: draft-cavanna-iscsi-crc-vs-cksum-00.txt
	Pages		: 8
	Date		: 28-Feb-01

The iSCSI working group is currently considering the method of
protecting iSCSI messages from errors. This I-D presents a proposal
to use the Fletcher-32 checksum algorithm.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-cavanna-iscsi-crc-vs-cksum-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-cavanna-iscsi-crc-vs-cksum-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-cavanna-iscsi-crc-vs-cksum-00.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 1 Mar 2001 15:10:31 -0800

Matt,

Interesting article, but a comment as usual.  There is very little
difference between Fletcher-32 and Adler-32 with respect to performance.
Fletcher Checksum is divided into two (16 bit) pieces, a straight 1's
complement sum and a higher order sum of the running sums.  The modulo in
Adler-32 is simply including a subtraction with a conditional branch.  As
Dafna pointed out, this test is normally done in a predictive manner by
means of linear coding lessening this difference between Fletcher and Adler
even further.  Data access in a table lookup required for CRC represents an
impediment whereas instruction cycles are easy hidden, so either Adler-32 or
Fletcher-32 will likely see a much larger throughput for software
implementations.  As Adler-32 is already advocated for SCTP and does not
represent anything substantially different with respect to performance to
that of Fletcher-32, I would be interested to understand the differences in
real-world situations.  Perhaps there is already a history of this
discussion within the sigtran archives.

Doug

Send a message to:
	[email-masked].
In the body type:

---

From: John H Howard <[email-masked]>
Date: Fri, 02 Mar 2001 08:42:25 -0500

CRC-32 is very expensive in software; it may require hardware assist in
fast networks.  Is iSCSI really intended to be a hardware only protocol?

Fletcher-32 has a serious flaw:  it does not distinguish between an
input halfword of all ones (FFFFx) and an input halfword of all zeros
(0000x).  Both are equal to zero under ones' complement addition. 
[Stone, J., Greenwald, M., Partridge, C., & Hughes, J., "Performance of
Checksums and CRC's over Real Data", IEEE/ACM Trans. on Networking,
Vol., 6, No. 5, October 1988] gives several examples of situations in
which this is important.

Adler-32 avoids this problem by adding 8-bit inputs into its 16-bit
sub-sums.  It also uses a prime modulus (2**16-15) rather than ones'
complement's 2**16-1.  Using 8 bit rather than 16 bit inputs doubles the
number of additions Adler-32 performs compared to Fletcher-32.  A more
subtle problem is that the high-order bits of the sums are not uniformly
distributed until the block size becomes very large.  I estimate that
this causes Adler-32 to lose one or two bits worth of resolving power. 
Still, a 30 bit checksum is still quite strong.

An alternative worth consideration is Fletcher-32 modified to use the
prime modulus 2**16-15.  It's fast, doesn't have the 0000=FFFF problem,
detects permutations, and distributes all result bits uniformly.  It
does confuse an input halfword of 0 with 2**16-15 (and similarly for
1..14), but I think this only a minor problem because the potentially
confused inputs are unlikely.  By definition every checksum confuses
many inputs.  If you are going to argue from bad examples you really
should estimate how likely your bad examples are.

John Howard
Sun Microsystems

---

From: Michael Krause <[email-masked]>
Date: Fri, 02 Mar 2001 11:08:12 -0800

>fast networks.  Is iSCSI really intended to be a hardware only protocol?

If one is attached to a high-speed network (Gbps and above), then hardware 
acceleration is a requirement to meet the customer performance 
objectives.  If a customer wants to attach to lower-speed networks, the 
impacts of using a CRC instead of a checksum are relatively in the "noise" 
range w.r.t. system resource utilization and overall performance.  As such, 
many of us favor using CRC-32 implementations - please see the e-mail 
proposal I sent out a month ago on how even a CRC-32 could be implemented 
to accelerate a software implementations while not penalizing hardware 
implementations.

Mike