Subject: RE: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpcsum-00.txt

From: [email-masked]
Date: Tue, 24 Jul 2001 21:45:27 -0400

I think the essence of Doug's argument is that having two
different CRCs in the protocol stack is better than using
the same CRC twice.  From a purely-iSCSI standpoint, this
actually yields a slight preference for CRC-32 (!) because
an integrity-conscious iSCSI connection will use in-band
CRC-32C, and hence having SCTP use CRC-32 provides two
different CRCs for the portions of the communication path
not covered by any link CRC-32.  OTOH, if one doesn't fully
trust any link CRC-32, having SCTP use CRC-32C makes sense.

My recollection of the list discussion was CRC-32 rather than
CRC-32C, as the discussion included observations that various
hardware implementations of CRC-32 were readily available.

--David

> -----Original Message-----
> From: Randall Stewart [mailto:[email-masked]]
> Sent: Tuesday, July 24, 2001 3:49 PM
> To: Douglas Otis
> Cc: Tsvwg
> Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpcsum-00.txt
> 
> 
> 
> Doug:
> 
> Thanks for your response.. I think we should be able
> to get a pint in london..
> 
> As far as why I specified CRC-32 ITU ... this is what
> I beleive the WG was discussing... Before I think
> we could adopt CRC-32c the WG would need to say this
> is what they really want...
> 
> So?? what do all of you feel out there??
> 
> The ITU CRC-32 aka same as ethernet OR is CRC-32c the
> one we should be going with??
> 
> R

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

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 25 Jul 2001 21:38:50 -0700

David,

iSCSI allows CRC32C to be negotiated and if placed over SCTP, there is not
any CRC overlap.  As the serial media CRC32ITU (IEEE-802.3) is permanently
used, then any argument for a different polynomial would clearly support use
of this polynomial within SCTP.  This concept would hinge on the difference
between larger packet coverage of CRC32ITU and that of CRC32C.  I would like
to think there is also a CRC32IETF and not a plethora of such polynomials.
I find it odd for you to suggest that the IPS work group arrived at CRC32C
as now documented but that the consensus was for CRC32ITU.  I do recall
those arguing for use of existing libraries but this lost to a greater
concern for integrity.  Perhaps you should also take a poll as to which CRC
is desired.

The most compelling document seemed to be:
http://www.ietf.org/internet-drafts/draft-sheinwald-iscsi-crc-00.txt

" 4.1 CRC (derivations from [Castagnoli93])

   In [Castagnoli93] it is reported that for epsilon=10^-6, Pud for a
   single bit error, for a code of length 8KB, for both cases, IEEE-
   802.3 and CRC32C is 10^{-20}. They also report that CRC32C has
   distance 4, and IEEE either 3 or 4 for this code length. From this,
   and the minimum distance of the code of this length, we conclude that
   with our estimation of epsilon, namely 10^{-11}, we should multiply
   the reported result by {10^{-5}}^4 = 10^{-20} for CRC32C, and either
   10^{-15} or 10^{-20} for IEEE802.3."

  "Wolf found that different shortened versions of a given code, of the
   same codeword length, perform the same (independent of which specific
   indexes are omitted from the original code). He also found that for
   the unshortened codes, all primitive polynomials yield codes of the
   same performance. But for the shortened versions, the choice of the
   primitive polynomial does make a difference. Wolf [Wolf94j found a
   primitive polynomial which (when multiplied by x+1) yields a
   generating polynomial that outperforms the CCITT one by an order of
   magnitude. For 32-bit, he found an example of two polynomials that
   differ in their probability of undetected burst of length 33 by 4
   orders of magnitude."

  "For the IEEE-802.3 used CRC32, Fujiwara [Fujiwara89] measured the
   weights of all words of all shortened versions of the IEEE 802.3 code
   of 32 check bits. This code is generated by a primitive polynomial of
   degree 32:
   g(x) = x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11 + x^10 + x^8 +
   x^7 + x^5 + x^4 + x^2 + x + 1 and hence the designed distance of it
   is only 3. This distance holds for codes as long as 2^32-1. However,
   the frame format of MAC (Media Access Control) of the data link layer
   in IEEE 802.3, as well as that of the data link layer for the
   Ethernet (1980) forbid lengths exceeding 12,144 bits. Fujiwara only
   investigated such bounded lengths. They found that for shortened
   versions, the minimum distance was found to be 4 for lengths 4096 to
   12,144; 5 for lengths 512 to 2048; and even 15 for lengths 33 through
   42.

   Fujiwara gives a chart of results of calculations of Pud from which
   we can see that for codes of length 12,144 and BSC of epsilon = 10^-5
   - 10^-4, Pud= 10^-14 - 10^-13 and for epsilon = 10^-4 - 10^-3,
   Pud(512,epsilon) = 10^-15
   Pud(1024,epsilon) = 10^-14,
   Pud(2048,epsilon) = 10^-13,
   Pud(4096,epsilon) = 10^-12 - 10^-11, and
   Pud(8192,epsilon) = 10^-10 which is rather close to 2^-32.

   [Castagnoli93] extended Fujiwara's technique for efficiently
   calculating the minimum distance through the weight distribution of
   the dual code and explored a large number of CRC codes with 24 and 32
   redundancy bit. They explored several codes built as a multiplication
   of several lower degree irreducible polynomials.
   In the popular class of (x+1)*deg31-irreducible-polynomial they
   explored 47000 polynomials (not all the possible ones - 2*(2^30-
   1)/31). The best that they found has d=6 up to block lengths of 5275
   and d=4 up to 2^31-1 (bits).
   The investigation was done in 1993 with a special purpose processor

   By comparison the IEEE-802 code has d=4 up to at least 64,000 bits
   and d=3 up to 2^32-1 bits.

   CRC32/4 (we will call it CRC32C in the rest of this memo) is
   11EDC6F41;  IEEE-802 CRC is 104C11DB7."

Doug

> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpcsum-00.txt
>
>