On 11/08/2014 12:22, Guus Sliepen wrote:
On Mon, Aug 11, 2014 at 12:00:11PM +0100, Etienne Dechamps wrote:
That said, I do agree that it is a much simpler solution compared to my
stateful conflict resolution proposal so it might not be that big of a
problem. I guess this makes sense if it allows us to make node identifiers
significantly smaller (with 48-bit it just doesn't matter, the chances of
collision are simply too small for the added complexity to be worth it). But
still, going from 48-bit node identifiers to as low as 24-bit would only
reduce overhead by 0.3 percentage points on a MTU-sized packet, so meh...
Honestly I doubt this is worth the effort.
The chance of the 48-bit hash failing is indeed very small, but if it
does fail it fails permanently for one or more nodes, unless you rename
them. Then I rather have something in place that, in this unlikely case,
may in itself fail, but at least has a lot higher chance to /do/ work.
But implementing the simplest solution with 48-bit hash and getting that
working is the first priority, then afterwards we can see if we want to
try out the salted hash version.
We can do that - after all, protocol versioning allows us to change the
identifiers in the future if needed.
I believe we don't have the same perspective on the design philosophy -
I prefer when failure modes are purely "black and white" - i.e.
communication between two nodes either works or it doesn't. I dislike
solutions where the system could "half-fail" in subtle and obscure ways
- like a node ending up in the same "hash bucket" as another, flapping
node, resulting in random packet loss. My rationale is that it's much
easier to diagnose clear-cut issues (two nodes can't talk to each other)
as opposed to spending hours trying to find out why some packets seem to
get lost on some links at random times.
--
Etienne Dechamps
_______________________________________________
tinc mailing list
[email protected]
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
