[tor-dev] an alternate MyFamily definition

tagnaq tagnaq at gmail.com
Thu Aug 23 17:03:06 UTC 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,

when requesting a new group by feature for compass [1] (#6662 [2]) I
discussed with Karsten about how to handle asynchronous/overlapping
families:

karsten:
> Here's an example. Assume we have three relays: A, B, and C. These
> relays state the following family relationships:
> 
> A: A, B B: A, B, C C: B, C
> 
> We require mutual agreement about being in the same family, so we
> could either come up with family A, B or with family B, C. Which
> one is correct?


I proposed to go with
family = A, B, C
because there is a mutual agreement between A<->B and  B<->C.

A and C agreed to be in a family with B, and B agreed to be in a
family with A and C.
Such configurations can be found in the wild mostly due to incomplete
MyFamily configurations on relays in big families.

As every big relay operator knows configuring families is a
non-trivial effort with a growing number of relays.
Now I thought about it and wanted to suggest this MyFamily
interpretation as an alternate approach to the fully mutual setup
where *every* relay must be reconfigured as opposed to just two of them.
Why?
This would reduce the configuration effort required when adding a new
relay to *two* relays regardless of how many relays are in your family.

Now, the MyFamily configuration overhead for big families is a well
known problem so I suppose someone else did already propose this approach?

What do you think about it?



[1] https://compass.torproject.org
[2] https://trac.torproject.org/projects/tor/ticket/6662	


a additional example to make this clearer:

A: A, B, C
B: A, B, C
C: A, B, C
D: A, B, C, D

family = A, B, C

A family member must have a *mutual* agreement with at least *one* node.
-----BEGIN PGP SIGNATURE-----

iF4EAREKAAYFAlA2YkoACgkQyM26BSNOM7Yp2wD/VTBw8BmUJlRZtIfXahIGX+t0
zwzP6MfRDwgPCsQMeEUA/3dUyyoq91Fx4lmihWHis2DZNAoM/CHh2MnwgMNL/W1W
=FWRU
-----END PGP SIGNATURE-----


More information about the tor-dev mailing list