Hey, On Tue, 15 Dec 2020 at 02:28, <nanog@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