how many bits of entropy do we need for load balancing?

Tue Dec 15 07:46:05 UTC 2020

Hey,

On Tue, 15 Dec 2020 at 02:28, <nanog at jack.fr.eu.org> wrote:

> There are 3 kind of hashing algorithm

I'm sure there are a lot more. Like 'cryptographic' purposes are
ambiguous. Proving that content hasn't been changed requires hash to
be fast and HW friendly, using hash to protect password requires hash
to be slow and HW unfriendly (i.e. SHAs are, by design, not good PW
hash, but confusingly we use them as such, since we think hashes as a
metric of 'good' and 'bad'.).
If you control the domain you can probably choose a non-compromise
solution, which is good specifically for that application but may not
be good for many others.

> The first one is used to check the sanity of input, against bit-swapping
> error for instance
> See CRC for instance
> Those algorithm are deadly fast, but also dumb as hell

Yeah CRC is quite good for the application it has, verify that the
1500B ethernet frame has not been changed, I believe it detects all
single and double bit flips

CRC is a canonical choice for router/switches to hash traffic, even
though CRC has really poor diffusion quality, which is the main metric
you're interested in hash for this application, I suspect CRC is a
canonical choice not because it's a good choice but because it's
already there. I know JNPR Trio for example runs two CRC functions
which makes the diffusion much much better, but no where near as good
as choosing a good algo for domain to begin with.

Of course no matter how great hash algo you have, we also have a
problem of elephant flows, which you cannot fix by improving the hash,
as you cannot reasonably expect to feed that info to the algo. And if
you do solve this problem, of course you solve it by biasing the
hash_result => egress_int table, and if you have the mechanism to bias
the mapping to ensure  fairness of traffic spread then the quality of
the algo becomes less important.

-- 
  ++ytti