Subject: RE: [Tsvwg] CRC-Straw Poll Update

From: Robert Snively <[email-masked]>
Date: Fri, 22 Jun 2001 10:17:08 -0700

My point is that CRC in the transport layer does not make
a transport layer reliable in the presence of bad 
hardware and software design.  Conversely, a simple
and fast transport layer checking mechanism together with
anything approaching good design practices provides 
transport layer reliability that is very excellent.

Data integrity that is desired to be better than 
something like one undetected error in 10**20 bytes +/-
some 2 or 3 orders of magnitude requires 
application specific checking mechanisms to be applied 
at the application end-point.  Therefore, the costs and complexity
implicit in a transport layer that strives for better reliability
than that threshold are probably ill spent.

Bob

>  -----Original Message-----
>  From: Douglas Otis [mailto:[email-masked]]
>  Sent: Tuesday, June 19, 2001 6:50 PM
>  To: Robert Snively; 'Randall Stewart'; TSV WG list
>  Subject: RE: [Tsvwg] CRC-Straw Poll Update
>  
>  
>  Bob,
>  
>  SCTP has a format that includes length and validation to 
>  assist such a fail
>  safe together with an initial all one's seed within the CRC 
>  algorithm.  From
>  conservative estimates of undetected errors, not based on 
>  the higher failure
>  rates of simple sums in the face of stuck memory bus errors 
>  or swapped
>  blocks, any business transaction would greatly benefit by a 
>  CRC algorithm.
>  Summation does not detect rather simple failures although it 
>  is indeed
>  faster.  What testing do you feel is needed in this area?
>  
>  Doug
>  
>  > If people are concerned about detection of marginal hardware
>  > failures, it is only fair to point out that most CRC hardware has
>  > multiple single points of failure, many of which do not 
>  "fail safe",
>  > but rather give a false indication that the CRC was valid. 
>   For that
>  > reason, the CRC is almost always supplemented with additional
>  > verification mechanisms, including verification of start/end
>  > characters, verification of various header contents, and coding
>  > violation checks.  Stuck faults of that nature can be tested using
>  > power-on-self-test routines, but marginal faults and faults that
>  > occur during an extended period of operation where diagnostics
>  > are not run are not revealed in any consistent manner.
>  >
>  > Bob
>  >
>  > >  -----Original Message-----
>  > >  From: Randall Stewart [mailto:[email-masked]]
>  > >  Sent: Tuesday, June 19, 2001 5:07 AM
>  > >  To: TSV WG list
>  > >  Subject: [Tsvwg] CRC-Straw Poll Update
>  > >
>  > >
>  > >  All:
>  > >
>  > >  After tabulating some others I had missed (thanks Ian)
>  > >  here is the current standings.
>  > >
>  > >  Take a close look for your name and verify that
>  > >  you are in the right class please (if you have
>  > >  specified a preference that is).
>  > >
>  > >  //////////////////////////////////////////////////
>  > >  PLEASE SOUND OFF IF YOU ARE IN THE WRONG
>  > >  CATAGORY!!!! OR I HAVE MIS-READ YOU.. Or maybe
>  > >  some that are in the 1/2 or 1/3 or 2/3 catagory
>  > >  could declare for only one please... it seems
>  > >  to me that in past elections double punching
>  > >  a vote was not allowed :=>
>  > >  //////////////////////////////////////////////////
>  > >  ***************************************************
>  > >  Not counted/Unspecified
>  > >  ***************************************************
>  > >  Wants Others to decide/No-comment (once bitten twice shy):>
>  > >  --------------
>  > >  Chip Sharp
>  > >
>  > >  No preference but wants only 1:
>  > >  -------------------------------
>  > >  Kacheong Poon ( wants only one sum, no options)
>  > >
>  > >  Still Unsure how to classify (Please speak up :>>):
>  > >  -------------------------------
>  > >  Ran Atkinson (wants justification for any switch)
>  > >
>  > >  *********************************************************
>  > >  Tabulated votes
>  > >  *********************************************************
>  > >  Keep the same (Option 1):
>  > >  -------------------------
>  > >  Ian Rytina
>  > >  Michael Tuxen
>  > >  Shymall Prasad
>  > >  Hanns J Schwarzbauer
>  > >  Alf Heidermark
>  > >  Klaus Gradischnig (wants keep the same or CRC-32) (.5)
>  > >  Qiaobing Xie (wants the same or Modifed-Alder ) (.5)
>  > >  Javier Pastor-Balbas
>  > >  Robert Snively
>  > >
>  > >  Use Modified Adler-32 (Option 2):
>  > >  ---------------------------------
>  > >  Gareth Kiely
>  > >  Qiaobing Xie (wants the same or Modifed-Alder ) (.5)
>  > >  Lyndon Ong
>  > >
>  > >  Use CRC-32 (Option 3):
>  > >  ----------------------
>  > >  Me
>  > >  Michael Ramalho
>  > >  Lloyd Wood
>  > >  Jonathan Wood
>  > >  Jim Williams
>  > >  Stephen Bailey
>  > >  La Monte Yarroll
>  > >  Ivan Arias Rodriguez
>  > >  Andreas Jungmaier
>  > >  David Black
>  > >  David Reed ** with preference for a MD5 Digest?
>  > >  Douglas Otis ** with preference for a MD5 Digest?
>  > >  David Lehmann
>  > >  Brian Bidulock
>  > >  Richard A. Adams
>  > >  Robert Fairlie-Cuninghame
>  > >  Wolfgang Schruefer
>  > >  John Loughney
>  > >  Laurent Glade
>  > >  Klaus Gradischnig (wants keep the same or CRC-32) (.5)
>  > >
>  > >  *********************************************************
>  > >  Summary Totals
>  > >  *********************************************************
>  > >
>  > >  Total 1) 8
>  > >
>  > >  Total 2) 2.5
>  > >
>  > >  Total 3) 19.5
>  > >
>  > >  Total unspecified) 3
>  > >
>  > >  ---------------------------------------------------
>  > >  Total folks commenting on: 33
>  > >  ---------------------------------------------------
>  > >
>  > >
>  > >  R
>  > >  --
>  > >  Randall R. Stewart
>  > >  [email-masked] 815-342-5222 (cell phone)
>  > >
>  > >  _______________________________________________
>  > >  tsvwg mailing list
>  > >  [email-masked]
>  > >  http://www1.ietf.org/mailman/listinfo/tsvwg
>  > >
>  >
>  > _______________________________________________
>  > tsvwg mailing list
>  > [email-masked]
>  > http://www1.ietf.org/mailman/listinfo/tsvwg
>  >
>  
>  

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

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 22 Jun 2001 13:14:42 -0500

Totally agreed. This is what I have been trying to tell the group.

-Qiaobing

---

From: "Douglas Otis" <[email-masked]>
Date: Fri, 22 Jun 2001 11:17:51 -0700

Robert,

You can not determine the hardware path of your data.  Should your data
enter a router outside your control that has a weak memory bus bit as
example, then summation protection is not near a level of assurance that a
company or individual will likely view as acceptable.  As a client, you may
not approve of the design practice used to make an XYZ component that
perhaps depends on ECC rather than a bus wide parity but these component
selections are not within your control.  Based on studies, reality does not
offer the ability to make assumptions about designs.  CRC within the
transport does offer assurances of being able to detect rather simple
hardware failures found in the path of the data, summations does not.  I
assume you would select software and hardware at your site that conforms to
your expectations.  CRC within the transport is not intended to protect
individuals making poor acquisitions of bad hardware or software.  It is
intended to provide protection when there is ulterior equipment that is
exhibiting a failure.  I can not see modifying thousands of applications to
include non-standard check acknowledgment and retry as being more cost
effective to using a reliable transport.  A weak error check in the face of
a simple hardware failure is ill conceived.

Doug

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Fri, 22 Jun 2001 16:07:14 -0400

All,

Darn it ... I agree with these comments but .... we are talking
about no additional bandwidth ..... and trivial computation
over the non-CRC32 proposals.

CRC-32 will catch 100% of the stuck at faults (assuming the
CRC is received correctly and the machine word length
is <= 32) ... which is *a* predominant error characteristic
that we would like to catch with near certainty.

I agree with the comments on the need for an application level
checksum if you need more assurance than the transport provides.

I think previous email discussed the complexity of the different
proposals in a software environment.

We all know that CRC's in general can be trivially computed
on the fly with hardware (32 flip flops and a few XORs, for the
case here). Can the same be said for Alder ... or would you
require a "dumb ALU" hardware for all the additions? If so .. the
hardware complexity of the non-CRC methods are at a
disadvantage in high-speed, hardware environments. Should
this issue be weighed as well? I happen to think that SCTP
could be used on high-speed hosts (web servers) eventually.

Still thinking that the small complexity (in a software
environment) for CRC-32 is worth it.

Michael Ramalho

As we know CRC's can be trivially computed with
> > than that threshold are probably ill spent.

Michael A. Ramalho, Ph.D.
Office email: [email-masked]
Personal email: [email-masked]
Office: +1.732.449.5762
Cell: +1.732.809.0188