[tor-relays] Qualities of a good relay (Sean Saito)

[nusenu]

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

> I’m currently working with Dr. Virgil Griffith on Roster, a tor 
> project that aims to reward relay operators with good relays.
> 
> Besides the obvious requirements of a good relay (e.g. speed, 
> geo-diversity, constant uptime), what qualities make a relay
> valuable to the Tor network and its users?

What are you generally aiming for:
1) a current rating (snapshot)
or
2) a rating that accumulates over time (like in distributed
computing/BOINC projects)?
or
1 + 2?

For the rest of this email I'm assuming you go for (2).


Start with what matters most:
- - Reward people for their total pushed traffic.

You could use it as the base value that gets multiplied by other
diversity/configuration factors.

- - Reward people running relays for a longer time.

(use a relay's age)

- - bandwidth
According to Roger one fast relay is more useful than many small relays.

Use bandwidth history (not advertised bandwidth).

- - Does the exit policy allow rare destination ports? more=better
(excluding *:25)

- - Does the relay's declared family match the effective family?

bigger diff = less good

Once [1] is implemented this will be really easy to check for.

[1] https://trac.torproject.org/projects/tor/ticket/16276

- - IPv6 connectivity

IPv6 enabled = better

- - Does the torproject want to reward non-announced 'exit_addresses'?
(as defined by onionoo)

- - Has the relay a contactinfo set?

non-empty is better

Certain people will scream "don't force people to disclose their email
addresses or link them to their relays".
I agree, but I'd say it is easy enough to create a new email address
for this purpose and people can also specify arbitrary strings there
(still more valuable than empty contacts if used consistently or
created by following a certain scheme).


- - Reward people running more than one relay.

You could simply use len(effective family) for that.

more relays = better

(until they reach some upper bound sum(CW) value?)
We don't want families to become to big in terms of CW fraction.
In practices you might ignore "the upper bound limit" since it is
unlikely that many ops will hit it anyway. And if more than one
strives for it the competition solves the problem itself.


Patch Level / Tor version / Supported Tor Handshake Types

- - Is the relay running a tor version
	- 'recommended' as per consensus
	and
	- free from known vulnerabilities (that is unfortunately not a
perfect overlap with 'recommended' as per dir auths)
	and
	- the latest version of one of the stable/supported version
	- using the latest


Does the torproject want to reward ops for running current alphas? You
probably want some but not all of the relays running alphas so this is
probably not suitable for automatic metrics.



Diversity

Judging by the latest paper on that topic it is good to start many
guards near your users (in terms of how many ASes need to be
traversed) and many exits near popular destinations, but I'm still
judging by another very simple approach that actually runs counter to
that: starting relays where there are none or few (by CW) is rated as
better than starting a new guard in the country where most users are.

So things to weight in for a quality measurement could be:

- - /16 netblock (by CW fraction, relay count)

- - country/region/city (by CW fraction, relay count (less important
than CW) and flags)
- - AS (by CW fraction, relay count (less important than CW) and flags)

Lower CW fr./ relay count in CC/AS is better.
goal: spread relays across the world

	Examples:
	- X added/runs a relay in a country and/or AS that had none or very
few before.
	- X added/runs an exit relay in a country and/or AS that had none or
very few before (no matter how many non-exits there are)

	Then you could "give out" rewards like "X started the first relay in
country/AS Y".

- - OS (by CW and relay count)

rare OS = better
(until people start to spoof their reported OS ;)



The calculation could look like this:

a new exit started, after 24 hours it did 700MB in a very common
AS/country/netblock, on Linux, with no contactinfo, with a great open
exit policy, running an unsupported tor version, declared+effective
family=0 ....

factors (purely invented):

exit relay factor: 2.7
common AS factor: 0.7
common cc factor: 0.8
common netblock factor: 0.6
common OS: 0.9
unsupported tor version: 0.1
family len 0: 1
...


700 * 2.7 * 0.7 * 0.8 * 0.6 * 0.9 * 0.1  * 1 * ... = X points

after 24 hours the relay is relocated to a rare AS/country/netblock,
changed its OS to OpenBSD and runs the latest tor version, effective
family changed to 2 and did 900MB more.

exit relay factor: 2.7
AS factor: 1.4
cc factor: 1.5
netblock factor: 1.7
OS factor: 2.5
recommended tor version: 1
family len 2: 1.05
..

points from day 1 +

900 * 2.7 * 1.4 * 1.5 * 1.7 * 2.5 * 1 * 1.05 ...


multipliers will have to be dynamically calculated as the tor network
changes.

I would love to see something like this implemented.

I'm really looking forward to your results.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJViq88AAoJEFv7XvVCELh0Wg4QALiAX3jeyCc/q5Gsfv0+zJh2
4oTdNkK1kHHIJ3aLZdgW4NE8xYnB0g+PrPQfOM6r4k+6RYlDrVBfblImUAKar9bG
q/t3tIgY7JT1t8tpmEk13SCgv0UFYYYSqykxjyIrdKgqAbcSiFTpw8TwjFZoTPcA
keacAsHxC83IllUmW3at3DBYrARiI7mTYxdHYnSaz5uQgLkn7RqZMR7lIILynJFX
55PFJZHVo11hw13vo//w8cNk2pVWqf3yivoqjNwOsrPqoy2OgkGBxiYX7q1Mvb3k
XQ3iTAvjhmWNJlUSchBh73CUFaNfSkj0AwCrtV6CQFQfqP1Jy9iBMjBnHS1EQjoX
KO6c0q+Ewl7k/DKLjJncT3OUfdBEg1ON5QUlComvyprvu+RimdQ7EQVKNC7aaDgD
LfaxhwzT3cISaAvfocf/paVsAbHgjSKTyNEAPtLxF9xrqwoU+r5vmp/qpdgHh16U
shKY9A9avmuJ8lwJx+UACZ8LoklOoykWSoBVwBUL21uuEWFOI5Y9EpY3Oi3SQnxY
urD97cXkT5ecTMnYwq7475ueBrIsEzb7aHkR4LJIKXDXVmBUpRHDfV5+uP6rNb6K
Q2YFEBm5PfMrvG3RAgoM0qJaYRAb1phtUYYhnfhL17hIUca5hs4emarfUb1oshZs
8r22I8pHNyZmmiG2lSTp
=atVx
-----END PGP SIGNATURE-----