Subject: RE: [Rserpool] Re: Adler-32 Checksum

From: Johnson Walter-CWJ002 <[email-masked]>
Date: Thu, 30 Jun 2005 08:56:02 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Lei
Sent: Wednesday, June 29, 2005 2:29 PM
To: Michael Tuexen
Cc: Xie Qiaobing-QXIE1; Thomas Dreibholz; [email-masked]; [email-masked]; 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:     [email-masked]
>  Homepage:   http://www.exp-math.uni-essen.de/~dreibh
> =======================================================================

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

---

From: Peter Lei <[email-masked]>
Date: Thu, 30 Jun 2005 10:06:02 -0500

> 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