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

From: Robert Snively <[email-masked]>
Date: Fri, 15 Jun 2001 07:31:14 -0700

A 32-bit bus with a stuck bit will be detected as an error 
with 100% probability using parity, which would normally be
expected on a bus having data integrity as a requirement. 
Even without parity, the stuck bit 
would also have a high probability of disrupting the header 
of the next packet, instantly flagging the bus as failing.  
In many of the other 32-bit buses (XGMII as an example), the
link CRC passes across the bus for link frame verification, which
supplements the packet verification.

While I am sure your numbers are valid, I think that ignoring
the benefits of the other checking mechanisms operating at the
same time creates unnecessary complexity and cost in the
packet verification algorithms.

Bob

>  -----Original Message-----
>  From: Douglas Otis [mailto:[email-masked]]
>  Sent: Thursday, June 14, 2001 5:08 PM
>  To: Robert Snively
>  Cc: [email-masked]
>  Subject: RE: [Tsvwg] sctp error check, again
>  
>  
>  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
>  
>  > 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
>  >
>  
>  

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

---

From: "Douglas Otis" <[email-masked]>
Date: Fri, 15 Jun 2001 11:26:10 -0700

Bob,

Within a larger system, the memory itself will likely be protected by ECC.
Some may consider ECC to be sufficient ignoring the physical bus.  Many
errors generated by a bus may be erratic due to a weak driver or poor
interconnect and thus not affect every operation and perhaps missed during
power-on diagnostics.  There are many smaller devices that interconnect
using busses that do not utilize error checks.  A client has no means to
determine the path of a packet or to know the quality of this path.  Faith
in these ulterior systems and the integrity of a simple checksum is
misplaced based on empirical data.  Whereas the client can determine the
transport and thus obtain a level of integrity not assured by ulterior
networking equipment.  Integrity at the transport allows a standard means of
assured communication.  The alternative is a patchwork of application level
retry and acknowledgment.

Doug