Some questions about SPTPS

[Etienne Dechamps]

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