Subject: RE: [Rserpool] Question on PE Checksum

From: Johnson Walter-CWJ002 <[email-masked]>
Date: Thu, 21 Jul 2005 16:47:06 -0500

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-masked]] 
Sent: Thursday, July 21, 2005 3:37 PM
To: Johnson Walter-CWJ002
Cc: Thomas Dreibholz; [email-masked]
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-masked]]
> Sent: Thursday, July 21, 2005 10:00 AM
> To: Thomas Dreibholz
> Cc: [email-masked]; 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-masked]
>>  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-----
>>
>

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

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 22 Jul 2005 09:43:00 +0200

Walter,

see my comments in-line.

Best regards
Michael

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

> 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.
It is clear at that level... But what kind of inconsistencies?
- A PE is registered at one side but not at the other.
- Differences in the data of a PE registered at both sides.
- ?
If one can not get any specific error model it is the best to assume  
that the 16 checksum will not detect
an inconsistency with a probability of 1/2^16.
>
> 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.
>
>