RE: Question on PE Checksum

The only inconsistency we are trying to detect is within the handlespace of the registrars. What we need to know is the probability that the PE Checksum calculated for a particular registrar will result in the same PE Checksum value calculated using different byte block data (incorrect registrar handlespace data). If different we want to synchronize our handlespace. Basically we want to have a consistent handlespace knowing which registrars own which PEs. 

If the PE checksum does match for different byte block data does it matter? Phrased another way, do the handlespace inconsistencies matter? I don't see a case where this matters from a basic operational standpoint.
     

-----Original Message-----
From: Michael Tuexen [mailto:[email protected]] 
Sent: Thursday, July 21, 2005 3:37 PM
To: Johnson Walter-CWJ002
Cc: Thomas Dreibholz; [email protected]
Subject: Re: [Rserpool] Question on PE Checksum

Hi Walter,

see my comments in-line.

Best regards
Michael


On Jul 21, 2005, at 21:49 Uhr, Johnson Walter-CWJ002 wrote:

> Not that I have verified this 32 bit Internet Checksum algorithm  
> (http://www.csee.usf.edu/~christen/tools/check32.c) for accuracy or  
> efficiency/optimization. But this seems to indicate a method where a  
> 32 bit Internet Checksum can be calculated using only a 32 bit  
> processor.
Just to be clear: I have not said that you can not compute the 32 bit  
checksum
on a 32 bit processor. What I wanted to point out out is that the  
common efficient
way of computing the checksum makes use of a larger integer type where  
you can accumulate
the overflows without having explicit statements for that in the code.

 From the code you cited:

     sum = sum + *((word32 *) addr)++;
     count = count - 4;
     if (sum < sum_last) overflow++;
     sum_last = sum;

The optimized versions do not have the last two lines of the inner loop  
shown above.
>
> If true, I guess my main concern is if people believe/know if moving  
> to a 16 bit Internet Checksum with its reduced ability of detecting an  
> inconsistency in the handlespace is better than using a non-optimized  
> 32 bit Internet Checksum hash or a very efficient 32 bit XOR hash  
> (instead of 16 bit Internet Checksum hash) which may not be optimally  
> spread/unique as compared to a 32 bit Internet Checksum but  
> potentially better than a 16 bit Internet Checksum.
My feeling (that means I can not prove it) is that we should use a  
checksum here and not an XOR. The 16 bit checksum
can be computed efficiently on every platform running IP, the 32 bit  
may or may not be computed as efficient.
The real question for me is: Do we need a better one than 16 bit  
checksum. What kind of inconsistencies are we expecting?
I have no idea on that. What do others think?
>
> Thanks
> Walter
>
> -----Original Message-----
> From: Michael Tuexen [mailto:[email protected]]
> Sent: Thursday, July 21, 2005 10:00 AM
> To: Thomas Dreibholz
> Cc: [email protected]; Johnson Walter-CWJ002
> Subject: Re: [Rserpool] Question on PE Checksum
>
> Thomas,
>
> the question is not if it is available in a programming language, but
> if it is available on all processors the protocol runs on.
> And that point is what I'm not sure about. And I'm not talking
> about about servers or workstations, but processors used in embedded
> devices and so on.
>
> The other point is that people do have some highly optimized code
> for the 16 bit stuff, but not for the 32 bit stuff. But they can build
> it if the processor supports 64 bit integer arithmetic.
>
> Best regards
> Michael
>
>
> On Jul 21, 2005, at 11:19 Uhr, Thomas Dreibholz wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On Thursday 21 July 2005 09:21, Michael Tuexen wrote:
>>> Hi Walter,
>>>
>>> I have looked into efficient ways of implementing the Internet
>>> checksum
>>> and figured
>>> out that you need 32 bit arithmetic to calculate the 16 bit checksum.
>>> When using
>>> a '32 bit Internet checksum' this would require support for 64 bit
>>> integers.
>>
>> Yes.
>>
>>> I do think that we should not require that.
>>
>> But is this really relevant on today's computers and compilers?
>> Working with
>> 64-bit integers ("long long" datatype) is for example part of the
>> ANSI-C
>> standard since ANSI C99 (http://www.nirvani.net/docs/ansi_c.pdf). This
>> standard is six years old.
>>
>> I think the effort to use the 32-bit sum is not significantly higher
>> than to
>> use the 16-bit sum; but the probability that handlespace
>> inconsistencies are
>> detected is.
>>
>>
>> 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 protected]
>>  Homepage:   http://www.exp-math.uni-essen.de/~dreibh
>> ====================================================================== 
>> =
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.2.4 (GNU/Linux)
>>
>> iD8DBQFC32im32BbsHYPLWURAjLRAJ0Rw450qEZypJ52M6vfxi+WGeU5fACfX1hY
>> 98Q/vzXnwNsqwmUEym2ILpc=
>> =8ijA
>> -----END PGP SIGNATURE-----
>>
>