Subject: [Tsvwg] sctp error check

From: Lyndon Ong <[email-masked]>
Date: Mon, 27 Aug 2001 22:39:08 -0700

Folks,

So far, we've only had one comment on the CRC type for SCTP - is there any
general leaning towards the ITU version vs. CRC-32c?

The ITU version has the weight of experience behind it, CRC-32c appears to
have some performance advantages - has there been much experience with
using it to date?

Cheers,

L. Ong

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

---

From: Randall Stewart <[email-masked]>
Date: Tue, 28 Aug 2001 07:06:17 -0500

Lyndon:

Thanks for prompting me... I have been meaning to summarize
an email on this but I have been to busy :/

I have heard of three actual version:

CRC-32-ITU
CRC-32-C
CRC-32-R

Now to summarize what little I have collected...

1) CRC-32-ITU

   advantages:
 
   a) It is well know and well used. 
   b) Hardware is already out there and available.
   
   disavantages:

   a) It protects a slight amount less in jumbo-grams (1 bit of
      hamming distance if I remember correctly).
   b) It is the same CRC being used at the link layer.

2) CRC-32-C

   advantages:

   a) It has a slightly better protection property (that we
      know of i.e. 1 bit)
   b) It is different then the link CRC's

   disadvantages

   a) It is less well known.
   b) Don't think I have heard of it applied in a transport protocol.
   c) It is probably not available in hardware off the shelf.
   d) I don't know how readily the cut/paste algorithms for 
      inserting pre-compiled CRC pieces of a packet together
      will work here... (Ran, you may want to read some of those
      papers I sent you... I have not had time ...sigh... to see
      if the algorithms can be adapted).

3) CRC-32-R

   I have no idea of what to put. It was mentioned by Michael R on the
   list... Michael? maybe you can fill this in... I would think its
   similar to CRC-32-C but if I remember right the IPS folks claim it
   does a bit worse...

Now one point I want to make about 1.b and 2.b above is that 
I do NOT see how a link.crc being the same has the transport.crc
makes that big of difference... here is why:

A) The principle goal of a transport protocol crc is to protect
   not on the links but instead in between.. i.e. in the router and
   in the transit between network card and SCTP stack. As such, having
   a different CRC then that of the link does nothing either way for
   this protection.

B) Seems to me the SCTP packet being protected is a wee bit different
than
   the CRC that will be generated over the entire wire level packet.
This
   is because there is a MAC header and a IP header added to the packet.
   I was under the impression that different CRC's are generated when
   you added more data... so I don't see that running the same CRC or
   different will even make that much difference on the actual wire.

So in summary I don't think that 1.b/2.b is hardly an advantage
or dis-advantage. It then comes down to 1 bit of hamming distance.
Yet Jonathan Stone and Craig Partridge's work seem to point that
bit errors are not the issue.. instead it is most likely packet
slice errors... 1 bit will not help in this case...

I would feel much more comfortable going for something well known
and well used considering all and all... but I do not really
have that strong of opinion.. I think having been bitten by
the "new checksum (aka Adler)" I would prefer something well known :>

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Tue, 28 Aug 2001 08:24:35 -0500

Randall Stewart <[email-masked]> writes:
...
>    b) Hardware is already out there and available.
...
> 2) CRC-32-C
...
>    c) It is probably not available in hardware off the shelf.
...

The Zilog ESCC controller line has hardware support for CRC-32-C.

---

From: "Douglas Otis" <[email-masked]>
Date: Tue, 28 Aug 2001 10:20:42 -0700

Randall,

To quote
http://www.ietf.org/internet-drafts/draft-sheinwald-iscsi-crc-00.txt

"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"

The distance differences is more than one bit for jumbo frames and offers a
significant difference to that of the ITU-CRC-32.

I would also like to raise some related issues.  The reflected table create
either a need to create a routine like flip_ntohl() to preserve the correct
order of the CRC results, but as this CRC value is located in the header,
the correct order may not be seen as important.  If you were to preserve the
correct order, this would be an advantage for Little Endian processors as it
would eliminate the need for byte reordering.

The next issue has to do with the initial CRC setting.  It is normally set
to all ones to ensure detection of leading zeros.

And one final issue is the inverted store.  When this done, it delineates
trailing zeros.  As this value is stored in the header, the advantages of
doing an inverted store has been removed.  This would change if the CRC was
placed at the end of the packet, but my impression was that this is too
great of a change to SCTP.

Doug