Subject: How many bytes should a CRC-32 protect?

From: Dr G Fairhurst <[email-masked]>
Date: Mon, 06 May 2002 16:07:26 +0100

I was asked by someone how big a frame size can a CRC-32 reasonably protect?

One of my students came across:

http://sd.wareonearth.com/~phil/jumbo.html

which seems to suggest that the CRC-32 is good for 10-12KB or so of
data, and that
this could be one reason why we don't see many subnetworks supporting
MTUs > 12KB.

Is there more wisdom out there on the use of CRCs over large subnetwork PDUs?
- perhaps the ATM or gigEthernet people have thought this one through?

Gorry Fairhurst.

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 6 May 2002 18:55:13 +0100 (BST)

On Mon, 6 May 2002, Dr G Fairhurst wrote:

> data, and that this could be one reason why we don't see many
> subnetworks supporting MTUs > 12KB.

well, much of the Internet core is typically up to around 9K mtu size
at the moment (SMDS IP mtu is 9180 bytes [RFC1209] and this was
adopted for AAL5 [RFC1626]). So why did the SMDS switching/bellcore
gang pick 9KB - 36B = 9188 - 8 bytes SNAP/LLC for their environment?

Core IP mtu size should imo be encouraged to grow gradually over time,
if only due to the tunnelling complexities of multiple recursive
(repeating-layer) encapsulations travelling through it - multiple
layers of vlans, vpns etc. If you're deploying a new network
technology, you'd want the same MTU size (i.e. existing fragmentation
logic already knows what to expect) or bigger to handle recursive
encap overhead.

[imo allowing larger TCP initial windows decreases the evolutionary
pressure on increasing subnet frame and mtu size for performance. The
TCP arithmetic checksum is weaker than a CRC-32 - how large a TCP
segment can you safely (as opposed to reliably...) send e2e, anyway?]

L.

> - perhaps the ATM or gigEthernet people have thought this one through?

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Matt Mathis <[email-masked]>
Date: Tue, 7 May 2002 11:38:49 -0400 (EDT)

The standard answer is 12KB, but I believe that this statement is based on an
engineering requirement that the maximum allowed probability that the CRC fails
to detect a corrupted packet is below some threshold.  (I would greatly
appreciate it if somebody can provide a specific reference for this
calculation.)

The logic behind the calculation seems to be flawed in the following way: If
you have a large quantity of data to move (say a Peta Byte, 1e+15 Bytes) then
the total undetected error rate is independent of the packet size across a huge
range of sizes.   This is because changes in per-packet exposure to undetected
errors are exactly offset by the change in the number of packets.

For example if I send 1e+15 bytes over a link that has a raw error rate of 
1E-12 then I compute:

Using 1000 byte packets:
 Raw bit error rate: 1.0e-12
 Per packet error rate: 1.0e-09
 Undetected packet errors: 2.5e-19
 Packets per data set: 1.0e+12
 Total undetected errors per data set: 2.5e-07

Using 10000000 byte packets:
 Raw bit error rate: 1.0e-12
 Per packet error rate: 1.0e-05
 Undetected packet errors: 2.5e-15
 Packets per data set: 1.0e+08
 Total undetected errors per data set: 2.5e-07

You can find some of my musing about the Internet cell size at
 http://www.psc.edu/~mathis/MTU/

Comments and feedback appreciated,
--MM--

-- 
--MM--
----------------------------------------------
Matt Mathis <[email-masked]>    W:412.268.3319
http://www.psc.edu/~mathis      H:412.654.7529
----------------------------------------------

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

---

From: Aaron Falk <[email-masked]>
Date: Tue, 07 May 2002 09:57:16 -0700

Matt-

You're assuming a uniform distribution of errors, aren't you?  If you have 
bursty errors (as in most wireless channels), you win with bigger packets 
since errors are concentrated in a smaller number of packets.

--aaron

> The logic behind the calculation seems to be flawed in the following way:
> If you have a large quantity of data to move (say a Peta Byte, 1e+15
> Bytes) then the total undetected error rate is independent of the packet
> size across a huge range of sizes.   This is because changes in
> per-packet exposure to undetected errors are exactly offset by the change
> in the number of packets.
>
> For example if I send 1e+15 bytes over a link that has a raw error rate
> of  1E-12 then I compute:
>
> Using 1000 byte packets:

---

From: Matt Mathis <[email-masked]>
Date: Tue, 7 May 2002 13:48:18 -0400 (EDT)

> since errors are concentrated in a smaller number of packets.

Well yes, perhaps.  Actually I think it depends on a whole bunch of assumptions 
about error distribution, and different terms can oposite effects.

The "hidden" model I used is that all raw errors cause the CRC to be uniformly
distributed actross 4e+9 values, one of which will cause a "false pass".

Thanks,
--MM--

_______________________________________________
pilc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/

---

From: Dan Grossman <[email-masked]>
Date: Tue, 07 May 2002 14:06:18 -0400

Some properties of CRCs are slowly bubbling up from the recesses of ancient
memory.  This with some uncertainty as to the accuracy of this memory, and which
are general properties of CRCs and which are properties of the CRC-32
polynomial.  Corrections are welcome.

A CRC of length N bits produces a unique codeword for packets of length 2^N-1
bits.  It will therefore detect any single bit error in a packet of that length
or less.

The particular polynomial (actually, all polynomials that either have or lack a
particular factor -- I think it was lacking an N(N+1) factor, but not sure) will
detect all odd numbers of errors.  It will detect all single bursts of less than
32 bits, and all 2 bit errors that occur within 2048 bits.  For all other even
number of bit errors, the probability of detection is 1-2^-32.

In practice, I recollect that the probability of undetected errors in a burst
error environment is difficult to solve analytically, and that people have tended
to do it by simulation.