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

From: Robert Snively <[email-masked]>
Date: Thu, 14 Jun 2001 08:41:29 -0700

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

>  -----Original Message-----
>  From: Randall Stewart at work [mailto:[email-masked]]
>  Sent: Wednesday, June 13, 2001 2:14 PM
>  To: Robert Snively
>  Cc: 'Ian Rytina'; [email-masked]
>  Subject: Re: [Tsvwg] sctp error check, again
>  
>  
>  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 11:07:26 -0700

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

---

From: Randall Stewart <[email-masked]>
Date: Tue, 19 Jun 2001 07:01:01 -0500

Bob:

I have been meaning to reply to this, and in my
scan for missed names I found it again :) 

I would have supported a TCP like 32 bit checksum
as well since it did prove to ALWAYS be the fastest
to implement. The reason I did not is that it is
completely unknown and un-studied. Having gone down
the Adler-32 path (silently I might add) I just can't see
changing from Adler-32 to another checksum that has
not been studied at all :-0

R