[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Rserpool] Re: Adler-32 Checksum
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.
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