Subject: RE: [Tsvwg] Another view of the SCTP error check problem

From: [email-masked]
Date: Tue, 26 Jun 2001 09:52:22 -0400

> Some of the answers are pretty obvious.  
> 
> 1) Any product that you have some chance of selling in
>    an enterprise environment will have an error rate through
>    all hops some seven orders of magnitude better than an 
>    ungroomed campus internet link.  
> 
> 2) Checking will be required at lower levels to achieve that
>    improvement, not so much to correct errors, but to isolate
>    devices and links that need to be replaced because they
>    are throwing too many errors.  That checking
>    will be included both in the links and in the boxes.
> 
> 3) Any application that really cares won't trust even those
>    probabilities and will provide additional verification at the
>    application level, principally to identify suspect
>    links and systems that have failed to perform their checks
>    correctly.
> 
> Once you have accepted the three answers above, why is
> CRC any better than a TCP-like 32-bit sum?

Unfortunately, all three answers are debatable and probably wrong:

(1) We care about environments other than the enterprise environment.
(2) Not all links can be relied upon to have that level of error detection.
(3) Application level checks should be a last resort for two reasons.
	a) The transport's retransmit algorithm is better engineered and
		more efficient - it should be the primary retransmit
algorithm,
		and leads to better network behavior when it is.
	b) If the transport can be relied upon to have a sufficient level of
		error detection underlying its retransmit, applications can
be
		significantly simpler.  If the response to the check failing
		can be designed under a worst-case assumption that the
		check will essentially never fail, then simple brute-force
		mechanisms (e.g., close the connection, try again) are ok,
		and lousy performance is acceptable.  Otherwise the
		response to a failed check has to be designed under a
		common-case assumption that its performance matters,
		and the result can be significantly more complex.

Beyond this, we know that the existing Adler-32 checksum
is broken for short packets, and there's an overwhelming
need for the fix to this to be permanent.  I would suggest
that this need for permanence significantly outweighs
the risk/costs of a CRC being overkill - based on the
respective track records of CRCs and checksums, a CRC
is the obvious choice to make sure that we never
have to revisit this issue again.  The computational
overhead argument against CRCs has been refuted on
this list, so I fail to see any compelling technical
objection to use of CRCs that remains.

IMHO, we can put a CRC in now and put this problem behind
us, or continue to debate the merits of various forms of
checksums to SCTP's detriment.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

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

---

From: "Douglas Otis" <[email-masked]>
Date: Tue, 26 Jun 2001 12:37:57 -0700

David and Bob,

If you look at the amount of data that will exist over the use of a product
where standards are hoped to remain over the next 15 years as a practical
measure.  If a 10 Gbit/second network were run over this duration at a 50%
average load in full-duplex, then operation for 473 million seconds totals
590 x 10^15 bytes.  The oft quoted Stone and Partridge paper "When The CRC
and TCP Checksum Disagree" indicates the raw error rate is between 1 in
11,000 - 32,000 of which a third was an ACK of FIN error.  This would
indicate that 36 x 10^12 to 12 x 10^12 errors will occur during this
interval.  If you trust that the majority of these errors are randomly
distributed, then CRC-32 should catch all of these errors over this
duration.  But as this paper indicates as much as 10% of these errors are
massive.  This would mean that a CRC-32 in the face of a massive error may
miss a few of these errors where the transport or application parsing will
likely detect them instead.  A checksum that can fail to detect 1% of these
errors if due to a bus or block related failure will not give any warning to
allow corrective action such as complaints to the provider or modification
of equipment.  If only .01% of these massive errors were related to bus or
block type of failure, then as much as 12 million undetected errors will
occur.  To answer Bob's question, what is the difference, 12,000,000 to 100.
This difference will allow the time to respond to a problem as David
indicates.  Bob's scheme does not where the mean time to an undetected error
would be on the order of 55 days versus 39 seconds.  Although not perfect, a
CRC-32 clearly provides the time to get a problem corrected whereas the
simple checksum does not.

Doug