[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Rserpool] Re: Adler-32 Checksum
The XOR is the simplest since the incremental update for both the addition/subtraction would be the same code. This is not the case for the Internet Checksum incremental update correct?
Basically is there some property of the Internet Checksum that improves it ability to detect a handlespace inconsistency since that is what we are concerned about. For instance does it have better spreading of the input data to result in better chance of a unique 32 bit PE checksum result?
Walter
-----Original Message-----
From: Peter Lei [mailto:peter.lei at ieee.org]
Sent: Thursday, June 30, 2005 10:06 AM
To: Johnson Walter-CWJ002
Cc: Michael Tuexen; Xie Qiaobing-QXIE1; Thomas Dreibholz; rserpool at ietf.org; rrs at cisco.com; Silverton Aron-C1710C
Subject: Re: [Rserpool] Re: Adler-32 Checksum
Johnson Walter-CWJ002 wrote:
> Is there any property that makes the Internet Checksum better at detecting a handlespace inconsistency as compared to a simple XOR of the byte block data which is composed of the pool handle zero padded to a 32 bit work boundary and the 32 bit PE Id?
>
> Wondering since the Internet checksum will be more computationally expensive.
I'm not sure what your concern is here. The Internet checksum
is just the ones's complement of (one's complement sum + carry).
That's two additional steps over a simple XOR sum.
The checksum has the property that it is endian independent (of
course the checksum is in the same endian as the CPU though).
--peter
> Thanks
> Walter
>
> -----Original Message-----
> From: rserpool-bounces at ietf.org [mailto:rserpool-bounces at ietf.org] On Behalf Of Peter Lei
> Sent: Wednesday, June 29, 2005 2:29 PM
> To: Michael Tuexen
> Cc: Xie Qiaobing-QXIE1; Thomas Dreibholz; rserpool at ietf.org; rrs at cisco.com; Silverton Aron-C1710C
> Subject: Re: [Rserpool] Re: Adler-32 Checksum
>
> Michael Tuexen wrote:
>
>>32 bits are longer and therefore better, but the 16 bit algorithm is
>>- already described in RFC 1071
>>- supported on NICs in hardware.
>>
>>Since it might be difficult to use a NIC to do the computation,
>>because RSerPool normally will be implemented in userland,
>>I would also vote for the 32 bit version and describe the
>>algorithm explicitly in the ENRP ID.
>>
>>If others agree I can put some text in the ID.
>
>
> I agree with using 32-bit checksum.
>
> --peter
>
>
>>Best regards
>>Michael
>>
>>On Jun 28, 2005, at 15:59 Uhr, Thomas Dreibholz wrote:
>>
>>On Tuesday 28 June 2005 15:53, Michael Tuexen wrote:
>>
>>
>>>>>>I think, the Internet checksum algorithm (may be with keeping the
>>>>>>full 32 bits
>>>>>>instead of truncating to 16 bits) should already be sufficient for
>>>>>>the audit
>>>>>>purpose. Using this checksum algorithm, we also get order-
>>>>>>invariancy and do
>>>>>>not need to force a specific ordering of the handlespace within a
>>>>>>management
>>>>>>component. It is furthermore very simple and fast (only + and ~
>>>>>>operations
>>>>>>are needed, no *, / or %).
>>>>>
>>>>>
>>>>>So the Internet checksum is the way to go... I have no particular
>>>>>preference
>>>>>in 16 bit or 32 bit.
>>
>>
>>I would prefer 32 bits. The checksum parameter pads the sum to 32
>>bits of
>>space anyway - so why not use the full 32 bits, making the
>>probability that
>>two states of the handlespace map to the same checksum value much
>>smaller?
>>
>>
>>Best regards
>>--
>>=======================================================================
>> Dipl.-Inform. Thomas Dreibholz
>>
>> University of Essen, Room ES210
>> Inst. for Experimental Mathematics Ellernstraße 29
>> Computer Networking Technology Group D-45326 Essen/Germany
>>-
>>-----------------------------------------------------------------------
>> E-Mail: dreibh at exp-math.uni-essen.de
>> Homepage: http://www.exp-math.uni-essen.de/~dreibh
>>=======================================================================
>
>
>
_______________________________________________
rserpool mailing list
rserpool at ietf.org
https://www1.ietf.org/mailman/listinfo/rserpool