Subject: RE: [Tsvwg] sctp error check, again

From: Robert Snively <[email-masked]>
Date: Thu, 14 Jun 2001 16:05:06 -0700

Doug,

I have seen at least one implementation that collects fragments
of information with separately developed checksums and assembles them
into packets using, not a recalculation of the overall checksum, but
manipulation of the partial checksums provided with each of the 
fragments.  Makes sense to me, and cannot be done very well with
most CRCs.  It detects all error bursts less than 32 bits long, it 
detects a bunch of other types of errors, and it rejects massive 
bursts with a worst-case failure rate of 1 in 2**32.  This is not 
half bad, and not significantly different than CRC.  The relevant 
buses range in width from 128 bits down to 1 bit, on a variety of 
bit and byte boundaries and with a variety of internal checking 
mechanisms which complement this detection capability.  As such, 
I don't really consider it "extremely susceptible to bus 
related errors".

Bob

>  -----Original Message-----
>  From: Douglas Otis [mailto:[email-masked]]
>  Sent: Thursday, June 14, 2001 11:07 AM
>  To: Robert Snively; 'Randall Stewart at work'
>  Cc: [email-masked]
>  Subject: RE: [Tsvwg] sctp error check, again
>  
>  
>  Robert,
>  
>  Such a simple checksum would be extremely susceptible to bus 
>  related errors.
>  Why would there be a need to change the content of the SCTP packet in
>  transit?
>  
>  Doug
>  
>  > I stand corrected.  I had not realized that the Adler-32 was
>  > the result of keeping it the same.  I support "none of the
>  > above", which is essentially what you have described below.
>  > A desirable candidate would be a 32-bit checksum using the
>  > 32 bit one's complement of the one's
>  > complement sum of all 32 bit words, making the assumption that
>  > any padded bytes have a value of zero.  This is essentially a
>  > 32-bit version of the TCP/IP check sum.
>  >
>  > I believe that this would facilitate implementations that
>  > make use of constructed packets or that require packet 
>  modification.
>  >
>  > Bob
>  >
>  > >  Bob:
>  > >
>  > >  The one thing that Jonathan seems to most strongly point
>  > >  out is NOT to use Adler-32... which it seems to me is
>  > >  not obvious in your forward..
>  > >
>  > >  So Jonathan recommends:
>  > >
>  > >  1) Moving the check to the end.
>  > >  2) Picking something DIFFERENT than Adler-32, even
>  > >     a 32-bit extension to the tcp sum (which I did test
>  > >     in my cpu tests and it does the best... but the down
>  > >     side is you are dealing with something completely 
>  unknown :-o)
>  > >
>  > >
>  > >  Bottom line is that Jonathan does not vote for our choice
>  > >  number 1... i.e. don't use adler-32 is plain in his post...
>  > >
>  > >  R
>  > >
>  > >
>  > >  Robert Snively wrote:
>  > >  >
>  > >  > Please consider the following e-mail, which correctly 
>  states that
>  > >  > not only is a checksum structure sufficient, but also 
>  that a CRC
>  > >  > is not any better in the real world, as long as both 
>  are developed
>  > >  > with a 32-bit check value.
>  > >  >
>  > >  > Bob
>  > >  >
>  > >  >> Jonathan Stone wrote:
>  > >  >>
>  > >  >>
>  > >  >> If there's anything i can recommend to the tsvwg, its to
>  > >  pick even a
>  > >  >> 32-bit extension of the TCP checksum, rather than 
>  Adler32; and to
>  > >  >> think seriously about moving the error-check bits to the
>  > >  end.  Not to
>  > >  >> help hardware, but to make whatever error-check you use
>  > >  more resilient
>  > >  >> against errors in packet-processing engines which (once
>  > >  an error does
>  > >  >> hit) trash the remainder of the packet.
>  > >  >>
>  > >
>  > >  --
>  > >  Randall R. Stewart
>  > >  [email-masked] 815-342-5222 (cell phone)
>  
>  

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

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 14 Jun 2001 17:08:12 -0700

Bob,

With a 32 bit bus stuck bit (0-31) applied to the last half of the packet,
1.3% undetected errors were experienced using Fletcher-16 (a 32 bit
summation result).  This is not near 2**32 indicating a summation to be
unreliable for bus related errors.  If errors are randomly distributed, then
simple summation has a chance of approaching 2**32 but busses do not
distribute errors randomly and, in many devices, not all provide the level
of protection desired.

As SCTP is a framing protocol, I am surprised to find a suggestion for a
partial frame construction technique.  One would think that a single pass
over the entire packet preferable.  However, if partial frames are assembled
in descending order, then it should not matter what algorithm is used.

Doug