netinet/cc: make use of arc4random()

[pfg]

Summary

Replace random() with arc4random(), this gives a bigger value of RANDOM_MAX.
It is likely the result will not be noticeable.

[cem]

sys/netinet/cc/cc_cdg.c

503

Forwarding my comments from the earlier review: I am hesitant to make unrelated type changes like this.

515–516

As I remarked before, this is now a different expression that is not purely a result of s/random/arc4random/. I don't really see any reason to try and expand this from 31 bits to 32 bits.

I don't know if unpredictability is significant in this context.

It may be significant that random(9) is actually the crappy rand(3) rather than the somewhat better (but still non-CSPRNG) random(3), for distribution purposes. If unpredictability doesn't matter, but distribution and speed does, a better solution might be to replace random(9) with random(3). Or another newish non-CS PRNG. Preferably dropping 'random' from the name.

sys/netinet/cc/cc_chd.c

87–88

As expressed before, I believe these function range definitions should live with the declarations in an appropriate header, rather than ad-hoc definitions in the .c file.

[pfg]

Add developers that are more likely to know better the code than me.

[tuexen]

Unpredictability is not important here, it is more the distribution. Any reason why the change has to happen?

[pfg]

In D22924#502329, @tuexen wrote:

Unpredictability is not important here, it is more the distribution. Any reason why the change has to happen?

Not really: when OpenBSD introduced arc4random(4), the idea there was to use it everywhere, and it seemed reasonable that we would follow the same principle so I had a much bigger patch replace random() everywhere in the kernel.

Part of the reasoning, although somewhat unscientific, is that feeding randomness to several different processes could have an effect of stripping the sequence for other processes so any stream will be even more unpredictable. I say the reasoning is unscientific because a good pseudo-random generator shouldn't have to rely on such tricks and striping some values in a biased manner may affect other properties of the random generator, but neither reasoning has been tested.

There is no hurry to commit this, I was just wondering if the replacement seems correct.

[pfg]

Abandon: it was not exactly right.

sys/netinet/cc/cc_cdg.c

503

After some review, this change is fine somewhat unnecessary. backoff looks more like a boolean.

515–516

Using the extra bit is a good idea: the return type is already unsigned.
Unfortunately this patch is screwed up since we would also have to revise EXP_PREC and probexp[].