Subject: Re: [dhcwg] Load Balancing for DHCPv6

From: Bud Millwood <[email-masked]>
Date: Thu, 6 Sep 2012 23:36:55 +0200

> Does anybody recall why the original load balancing had the 16 byte
> restriction?
>
>
> Nope.   It might be worth visiting the question of whether the hash
> algorithm is the right one.

Any particular reason for revisiting the hash algorithm itself, as
opposed to just dropping the 16 byte limit in DHCPv6?

- Bud

---

From: Andre Kostur <[email-masked]>
Date: Thu, 6 Sep 2012 14:43:59 -0700

> opposed to just dropping the 16 byte limit in DHCPv6?

Personally I don't think we need to revisit the algorithm.  I have not
heard of anybody complain about it, and existing DHCP servers and
relays (assuming they're doing load balancing now) will already have
the implementation done.   I think the 16 byte limitation should just
be lifted.   In the common cases of ethernet-based networks, DUID-LLT
is 14 bytes (below the 16), DUID-LL is only 10, and DUID-UUID is 18
bytes (only 2 beyond the 16).  The only one that is more of a question
mark is DUID-EN as the vendor-specific identifier could be of
arbitrary length.  The one case that we've heard of so far puts the
length at 13 bytes + the length of a serial number.

I'll wait for this discussion before I publish an updated draft to
reflect this topic.

--
Andre Kostur

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Sep 2012 21:44:15 +0000

> opposed to just dropping the 16 byte limit in DHCPv6?

I don't actually remember the criteria that were used to choose the old hash algorithm.   Are we still happy with it?   Things have changed since the previous draft was published.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 6 Sep 2012 21:58:44 +0000

I think the algorithm is fine. We've never run into any operational issues with it.

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 07 Sep 2012 11:49:11 +0200

> arbitrary length.  The one case that we've heard of so far puts the
Sort of arbitrary, until you hit the limit of 128 octets, imposed by
3315 section 9.1. I'm ok with lifting the 16 bytes limit (or rather
extending it to 128 bytes).

There are some devices out there that are using DUIDs with duid type 14.
I have no idea what those devices are, I just saw traffic captures from
a production network. It is odd, but any server that follows 3315,
section 9 ("servers MUST treat DUIDs as opaque values") will handle them
ok. Anyway, my recommendation is to include the whole DUID as is in the
hash and don't to any clever things with duid types.

Regarding hashing algorithm, I never heard anyone complaining about it.
So don't fix it if it isn't broken. It can handle data chunks up to 128
bytes, right?

Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 7 Sep 2012 11:16:25 +0000

Yes it can handle any length of data - the 16 limit came from max of chaddr. There is no harm in using whole duid, skipping type just reduces bytes used and as that field varies little it adds little.

Sent from my iPad

On Sep 7, 2012, at 5:49 AM, "Tomek Mrugalski" <[email-masked]> wrote:

> Regarding hashing algorithm, I never heard anyone complaining about it
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 7 Sep 2012 10:44:35 -0400

If it is working fine, there is certainly no reason to change it,
which could lead to interoperability problems. But I'd be willing to
bet that FNV is superior...
https://datatracker.ietf.org/doc/draft-eastlake-fnv/

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Sep 2012 15:27:32 +0000

> bet that FNV is superior...

There's no risk of an interoperability problem, since DHCPv6 and DHCPv4 never interoperate.   However, the advantages of the hash mentioned in the draft are pretty handwavy.  Is there any more detailed analysis somewhere?

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 7 Sep 2012 17:37:19 -0400

Hi Ted,

> There's no risk of an interoperability problem, since DHCPv6 and DHCPv4 never interoperate.   However, the advantages of the hash mentioned in the draft are pretty handwavy.  Is there any more deta…

Here is one study done by Brian Carpenter related to equal cost
multi-path hashing based on the IP 5-tuple:
https://researchspace.auckland.ac.nz/bitstream/handle/2292/13240/flowhashRep.pdf?sequence=2

Here is a study done by Puneet Agarwal (of Broadcom) related to equal
cost multi-path hashing based on Layer 2 headers:
http://www.ieee802.org/1/files/public/docs2011/bp-agarwal-hash-proposal-0411-v03.pdf

FNV takes a little more effort than Pearson. It also has a smaller
footprint in memory. And I believe it will produce statistically
better results. What are the relative weights of these or other
factors in this case?

Thanks,
Donald

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Sep 2012 22:29:20 +0000

> better results. What are the relative weights of these or other

Unfortunately, as far as I can tell neither of the studies you cite compares FNV to Pearson, although the results from Brian Carpenter's study are certainly pretty impressive.    I think more work is worse, smaller footprint probably doesn't matter (this algorithm is being run in DHCP servers, which typically aren't seriously memory-constrained), and statistically better results only matter if it's a pretty big difference, so it's frustrating that we don't have a comparison to the existing algorithm.

To me, the biggest win of using FNV would be if there were an RFC to refer to, but it looks like this is not quite there yet.   So my conclusion is that I certainly don't oppose using FNV instead of Pearson, but I don't see a strong reason to support it either.

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 8 Sep 2012 19:35:47 -0400

How much of a rush is there on this?

I've sent a message to Brian Carpenter asking if he could run his test
data with Pearson to compare with FNV.

The FNV draft has been presented at a SAAG meeting and the comments
received resolved. I think it is in quite good shape. I just need to
finish up the source code. Maybe this is just the incentive I need :-)

Thanks,
Donald

---

From: Ted Lemon <[email-masked]>
Date: Sun, 9 Sep 2012 02:50:39 +0000

> How much of a rush is there on this?

I don't think there's a huge rush, but Andre might disagree... :)

---

From: Andre Kostur <[email-masked]>
Date: Sun, 9 Sep 2012 07:42:59 -0700

> I don't think there's a huge rush, but Andre might disagree... :)

Other than keeping the draft moving along....

Does the WG want to take this on as a working item?  I think we can
get that part of the draft process resolved (and possibly publish
draft-ietf-dhc-loadbv6-00) while we're waiting for the results of
Pearson vs. FNV.

--
Andre Kostur

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 10 Sep 2012 11:51:53 -0400

Moving this to a WG draft seems reasonable.

It appears that it is hard for several different reasons (the grad
student who did all the work is gone, Brian is now fully retired and
about to go on a month's vacation, etc...) for Brian Carpenter to just
run the same test on Pearson but he can probably do some lesser amount
of testing. I'm continuing to converse with him on this...

Thanks,
Donald

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 13 Sep 2012 03:15:50 +0000

One comment on the draft is that I think it needs to be clear that load balancing is ONLY used for DHCPv6 client messages that do not include a server-identifier option (this is Solicit, Information-Request (if no server-identifier option), Rebind, and Confirm). Load balancing MUST NOT be used if a server-identifier option exists in the client's message, as then only that server should respond.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Donald Eastlake
Sent: Monday, September 10, 2012 11:52 AM
To: Andre Kostur
Cc: [email-masked]; Ted Lemon
Subject: Re: [dhcwg] Load Balancing for DHCPv6

It appears that it is hard for several different reasons (the grad student who did all the work is gone, Brian is now fully retired and about to go on a month's vacation, etc...) for Brian Carpenter to just run the same test on Pearson but he can probably do some lesser amount of testing. I'm continuing to converse with him on this...

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA  [email-masked]

---

From: Andre Kostur <[email-masked]>
Date: Tue, 18 Sep 2012 09:04:06 -0700

On Wed, Sep 12, 2012 at 8:15 PM, Bernie Volz (volz) <[email-masked]> wrote:
>
> One comment on the draft is that I think it needs to be clear that load
> balancing is ONLY used for DHCPv6 client messages that do not include a
> server-identifier option (this is Solicit, Information-Request (if no
> server-identifier option), Rebind, and Confirm). Load balancing MUST NOT be
> used if a server-identifier option exists in the client's message, as then
> only that server should respond.

I've been mulling this over for a while in the context of the following problem:

Let us assume that there are two cooperating (through some additional
mechanism external to load balancing) DHCPv6 servers A and B.  At some
point, server A goes away for a while and the entire population
eventually binds to server B (whether rebooting, or Rebinding to it).
 Now server A returns to service.  Until the members do a reboot or
Rebind, server A will not be handling any traffic (other than about
1/2 of the new clients) as server B is receiving and answering all of
the Renews.  What I'd like is that over time, the population will
migrate around to splitting between server A and server B again.

I think for this reason we shouldn't force the server to answer (well,
consider) every request aimed at it.

--
Andre Kostur

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 18 Sep 2012 16:24:06 +0000

First, I think this would be a rather bad change to DHCPv6 operation.
Client may be checking the server-identifier option they get back and so
you would have to lie about that in the response which just seems like a
very bad thing to do. (I don't believe RFC 3315 actually ever states the
clients should be checking the server-identifier, but I could be wrong --
section 15 does say they check for the presence of the option, but do not
check the contents). One could also think of situations where a relay
agent might forward the packet to explicit destinations based on the
server identifier (though again, I doubt anyone does this) -- much like
switches limit traffic based on mac-addresses.

Second, the following assumes load balancing is being used for failover ...

There is one 'trick' that I had been thinking about for a long time and is
perhaps still an open issue for failover for v6 Š and that is why not have
both failover partners use the same server-identifier value (you can think
of the server-identifier belonging to that failover relationship) -- then
the servers can always use load balancing or other 'policy' to decide
which one responds and you don't violate the concept that the
server-identifer is the one that the client expects.

It also means that Renew packets can be handled by either partner.

However, it does complicate Request packets because failover doesn't
usually exchange tentative bindings from a Solicit and so you really would
only want the server that Solicited to respond to the Request (this could
be done by looking to see if you had a tentative binding - but if neither
server does, the client has to suffer a Request timeout to get back to the
Solicit phase).

--> That is the main reason why I think this fails to work and I have not
proposed it.

Also, note that you would potentially have this same issue for your
proposal when 

For v4, the current operation has not really caused operational issues. We
have thought about how to 'force' traffic back to the original server but
as it hasn't caused any issues, we haven't bothered? New v4 clients (i.e.
those that do a discover), will get back to their server and most clients
seem to do so over a reasonable period of time.

Anyway, I think this needs to be thought through much more carefully as to
the potential consequences and I think the best is to keep it simple -
once a client has 'bound' to a server, it stays with that server until it
issues a request message which does not contain a server-identifier option.

- Bernie

---

From: Andre Kostur <[email-masked]>
Date: Tue, 18 Sep 2012 09:42:44 -0700

> switches limit traffic based on mac-addresses.

Note that I didn't suggest that server A preemptively answer the Renew
coming in from the client (or impersonate server B).  Under my
suggestion, the Renew would arrive at both servers A and B.  B would
ignore it due to load balancing, and A would also ignore it due to the
server ID.  The client continues to retry the Renews for the
appropriate time, until it is time to Rebind.  At that point server B
is still ignoring the client, but now A can answer the client as the
Rebind isn't carrying a Server ID.  (And if we are talking about a
Failover pair, then server A would already have a lease record for
this client, and can extend that same lease.)

For the relay piece, it would still need to forward the Rebind to both servers.

[snip]

> issues a request message which does not contain a server-identifier option.

My scenario doesn't result in a client switching servers except under
already defined RFC 3315 behaviour when the client has transitioned
into Rebind.

One piece that may have funny consequences is if the pair of DHCP
servers aren't in some sort of cooperation mode, and this scenario
would result in the client possibly changing IP addresses.  Client has
to rebind, and server A does the DHCPv6 equivalent of a NAK and forces
the client to come back to get a new IP.    Perhaps a server MAY skip
the load balancing if the packet contains a Server ID (or even
limiting it to the server's Server ID)?

-- 
Andre Kostur

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 18 Sep 2012 17:44:03 +0000

OK Š though having the client send lots of Renews seems less than optimal
to me (and the limited processing required by the load balancing servers
for these packets may be more than if the targeted server just answered
the first time).

I think this could always be an optional feature. Even if the servers had
different settings with respect to handling Renews, things would still
work correctly.

- Bernie

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 20 Sep 2012 01:27:09 -0400

Well, I have some more statistics. One my co-authors on the draft
whipped up some code that I then extended. The data hashed consisted
of 2,560,000 strings calculated as follows:
        #define RUN 10000
        for(i = 0; i < 256*RUN; ++i)
{
                sprintf(str, "%08d^^%08d", i, i);
                {do hashes, etc}
}

Each string was hashed with Pearson and with 32-bit FNV-1a. Three
arrays of 256 counters were incremented based on the Pearson hash,
based on the bottom byte of the 32-bit FNV after one 16-bit fold (
hash2 = (hash&0xffff) ^ (hash >> 16) ), and based on the bottom byte
of the 32-bit FNV after an additional 8-bit fold (hash3 = (hash2&0xff)
^ (hash2 >> 8); the equivalent of xor'ing all four bytes together).
The expected number of hits on each bucket with perfect hashing would
be 10,000. Here are the minimum and maximum number of hits and the
standard deviation:

Pearson: min=9678 max=19938 std-dev=630.72
FNV-32 1-fold: min=9699 max=10331 std-dev=103.06
FNV-32 2-folds: min=9662 max=10247 std-dev=90.78

So you now have Brian Carpenter's results, showing FNV to be much
better than a variety of other methods, but not Pearson, on fairly
realistic data. And you have these results showing FNV to be much
better than Pearson on somewhat unrealistic data. ...

Thanks,
Donald

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 20 Sep 2012 12:05:16 +0000

Bad test - This is a very limited character set.

The data usually used for dhcp is binary data.

Sent from my iPad

---

From: Bud Millwood <[email-masked]>
Date: Fri, 21 Sep 2012 15:32:45 +0200

Andre:

I think the only reasonable way to move clients back to server A is
what you suggest. You are essentially doing the same thing as the
failed server A did when it failed - going offline - but you're just
doing it administratively, and just for a subset of clients. It causes
a degraded performance mode on your network, but you have to balance
that against the desire to split the load after server A has come back
online.

It's not a failover problem so much as it's a load balancing problem.
For example, suppose you wanted to change the load balancing split to
70/30 instead of 50/50 on a running network - you'd use the same
mechanism.

> server does, the client has to suffer a Request timeout to get back to the

Is this a problem because under normal circumstances, the server could
allocate a lease on the spot in response to the Request (i.e., without
having seen a Solicit)? It seems like a reasonable tradeoff - to
disallow a failover partner from short-circuiting the full lease
transaction.

- Bud

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 21 Sep 2012 14:36:56 +0000

Bud:

> the server could allocate a lease on the spot in response to the Request (i.e., without having seen a Solicit)?

Correct.

As this address (or prefix) is likely in other-available, the server would not be able to assign it. But with DHCPv6, it can provide an alternative -- it is the Reply that matters (this is one difference over DHCPv4 where the server would be forced to NAK - or just drop the packet).

---

However, Andre's proposal would be that if the server-duid matches but load balancing says that this is not the server that should be responding, to drop the request. This would thus force the client to return to Solicit (when the Requesting times out) or to advance to Rebind (when renewing between T1 and T2). This would work to move the client to the "correct" server but it does increase the traffic and load for those packets that are dropped.

This would generally only impact Request and Renew packets. I would think that the server should always process Release and Decline since those are limited in their retransmissions (and the client fallback is to stop sending).

So, I think when both failover partners are responsive the load balancing processing would be:
- If server-duid not represent in request (Solicit, Rebind, Confirm, Information-Request), use load balancing to determine if server responds.
- If server-duid present and doesn't match this server, drop packet (standard RFC 3315).
- (server-duid present and matches server), if Request or Renew still use load balancing to determine if server responds.
- Otherwise respond to client.

- Bernie

-----Original Message-----
From: Bud Millwood [mailto:[email-masked]] 
Sent: Friday, September 21, 2012 9:33 AM
To: Andre Kostur
Cc: Bernie Volz (volz); [email-masked]; Ted Lemon
Subject: Re: [dhcwg] Load Balancing for DHCPv6

Andre:

I think the only reasonable way to move clients back to server A is what you suggest. You are essentially doing the same thing as the failed server A did when it failed - going offline - but you're just doing it administratively, and just for a subset of clients. It causes a degraded performance mode on your network, but you have to balance that against the desire to split the load after server A has come back online.

It's not a failover problem so much as it's a load balancing problem.
For example, suppose you wanted to change the load balancing split to
70/30 instead of 50/50 on a running network - you'd use the same mechanism.

Bernie:

> usually exchange tentative bindings from a Solicit and so you really 
> would only want the server that Solicited to respond to the Request 
> (this could be done by looking to see if you had a tentative binding - 
> but if neither server does, the client has to suffer a Request timeout 
> to get back to the Solicit phase).

Is this a problem because under normal circumstances, the server could allocate a lease on the spot in response to the Request (i.e., without having seen a Solicit)? It seems like a reasonable tradeoff - to disallow a failover partner from short-circuiting the full lease transaction.

- Bud

On Tue, Sep 18, 2012 at 6:42 PM, Andre Kostur <[email-masked]> wrote:
>> Client may be checking the server-identifier option they get back and 
>> so you would have to lie about that in the response which just seems 
>> like a very bad thing to do. (I don't believe RFC 3315 actually ever 
>> states the clients should be checking the server-identifier, but I 
>> could be wrong -- section 15 does say they check for the presence of 
>> the option, but do not check the contents). One could also think of 
>> situations where a relay agent might forward the packet to explicit 
>> destinations based on the server identifier (though again, I doubt 
>> anyone does this) -- much like switches limit traffic based on mac-addresses.
>
>> Anyway, I think this needs to be thought through much more carefully 
>> as to the potential consequences and I think the best is to keep it 
>> simple - once a client has 'bound' to a server, it stays with that 
>> server until it issues a request message which does not contain a server-identifier option.
>

---

From: Andre Kostur <[email-masked]>
Date: Fri, 21 Sep 2012 07:52:45 -0700

One note about the failover part of this dicussion.  I note that the
v4 load balancing was split away from the failover discussion (and
this draft is trying to follow v4 load balancing), and as such the
load balancing needs to be able to work in the absence of failover.
Perhaps the two servers are sharing IP space, say a 50/50 split of a
/64.

On Fri, Sep 21, 2012 at 7:36 AM, Bernie Volz (volz) <[email-masked]> wrote:
> However, Andre's proposal would be that if the server-duid matches but
> load balancing says that this is not the server that should be responding,
> to drop the request. This would thus force the client to return to Solicit
> (when the Requesting times out) or to advance to Rebind (when renewing

The Solicit to Request should be a pretty rare problem.  This would
have to occur if the server that had answered the Solicit failed
before the device managed to get its Request in.  And in that case, I
don't think making it retry the Solicit is unreasonable.

> between T1 and T2). This would work to move the client to the "correct"
> server but it does increase the traffic and load for those packets that are
> dropped.

It may increase the total traffic load, but functions to migrate the
load away from one server to split it again to two.  (Or as Bud had
mentioned, make a new division instead of 50/50)

> This would generally only impact Request and Renew packets. I would think
> that the server should always process Release and Decline since those are
> limited in their retransmissions (and the client fallback is to stop
> sending).
>
> - If server-duid not represent in request (Solicit, Rebind, Confirm,
> Information-Request), use load balancing to determine if server responds.

Yep.

> - If server-duid present and doesn't match this server, drop packet

Yep.

> - (server-duid present and matches server), if Request or Renew still use
> load balancing to determine if server responds.

Yep, contemplating the other packet types.

> - Otherwise respond to client.

One thing that I think has been overlooked, what about the Relay that
may be doing Load Balancing?  It doesn't have the server's DUID to
make this comparison at all, and thus cannot do this determination.

--
Andre Kostur

---

From: Andre Kostur <[email-masked]>
Date: Fri, 21 Sep 2012 09:43:59 -0700

I've crafted up a test rig for Pearson vs. FNV1a   (Pearson code from
the RFC, FNV1a from
http://isthe.com/chongo/tech/comp/fnv/#FNV-reference-source, with the
XOR-folding at http://www.isthe.com/chongo/tech/comp/fnv/index.html#xor-fold).

I generated my DUIDs as a set of DUID-LLs (so the first four bytes are
00, 03, 00, 06).  The next three were taken randomly from IEEE's list
of registered OUIs.  The remaining three are rand().

Running those through both Pearson and FNV1a 5 times each (on a set of
2,560,000 DUID-LLs) resulted in:

Pearson:
Min: 9637 - 9750, Max: 10220 - 10318, StdDev: 92.91 - 102.28

FNV1a:
Min: 9691 - 9754, Max: 10221 - 10379, Stdev: 93.27 - 107.66

This seems to suggest that Pearson is better than FNV1a over DUID-LLs.

-- 
Andre Kostur
Distinguished Software Architect & Engineer
P: 604-678-2864
E: [email-masked]
Toll-Free: 1-800-877-1856

F: 604-678-2864
VoIP: sip:[email-masked]

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 21 Sep 2012 17:04:48 +0000

Thanks Andre.

While it would make no difference, it is always a mystery whether DUID will use a hardware type of 1 or 6. Per http://www.iana.org/assignments/arp-parameters/arp-parameters.xml, type 1 is for Ethernet whereas 6 is for IEEE 802.3.

It may well be for a more limited data set (i.e. ASCII strings), FNV1a could be better. I think Pearson was optimized for binary data.

My feeling is we should stick with Pearson and use the entire DUID (no length limit).

- Bernie

-----Original Message-----
From: Andre Kostur [mailto:[email-masked]] 
Sent: Friday, September 21, 2012 12:44 PM
To: Bernie Volz (volz)
Cc: Donald Eastlake; [email-masked]; Ted Lemon
Subject: Re: [dhcwg] Load Balancing for DHCPv6

I've crafted up a test rig for Pearson vs. FNV1a   (Pearson code from
the RFC, FNV1a from
http://isthe.com/chongo/tech/comp/fnv/#FNV-reference-source, with the XOR-folding at http://www.isthe.com/chongo/tech/comp/fnv/index.html#xor-fold).

I generated my DUIDs as a set of DUID-LLs (so the first four bytes are 00, 03, 00, 06).  The next three were taken randomly from IEEE's list of registered OUIs.  The remaining three are rand().

Pearson:

FNV1a:

On Thu, Sep 20, 2012 at 5:05 AM, Bernie Volz (volz) <[email-masked]> wrote:
>> of the 32-bit FNV after an additional 8-bit fold (hash3 = 
>> (hash2&0xff) ^ (hash2 >> 8); the equivalent of xor'ing all four bytes together).

F: 604-678-2864

---

From: Andre Kostur <[email-masked]>
Date: Fri, 21 Sep 2012 10:12:20 -0700

Whups, yep.  Changed that to a 1, and no significant different in the
stddev.  Both still in that 95 - 105 range.

I'm also of the opinion that Pearson is the way to go.  Seems to give
a pretty good spread of values, it's already documented in RFC
(complete with implementation), and any servers or relays that may
have already been doing load balancing for v4 will already have this
algorithm implemented.

-- 
Andre Kostur

---

From: Andre Kostur <[email-masked]>
Date: Fri, 21 Sep 2012 11:05:31 -0700

Bernie had asked off-list (and I was kinda curious myself) as to the
relative performance of the two algorithms as well.  So I put it under
a performance analyzer, and it came back with Pearson taking on
average 0.67 usecs per invocation, where FNV1a took 1.50 usecs per
invocation.  (That is on an optimized build of the algorithms, not
debug builds.)

Add this to all of the other reasons already mentioned, I think Person
is definitively the way to go.   (Unless someone can point out a flaw
in my methodology....)

-- 
Andre Kostur