Hi nusenu,
Do you consider in-family diversity so important - even though all of them are run by a single entity anyway? How about having a badge for tor network wide diversity? I'd consider the tor network's overall diversity far more important than in-family diversity because clients won't use more than one relay of a given family anyway.
Entire-network diversity is obviously more important than within-operator diversity---no doubt about that. We are doing within-operator diversity simply because the it's easier to measure/understand. I agree that measuring a family's relay diversity with respect to the entire Tor network is would be supplementary, maybe even strictly better. I am already logging relevant data, namely the number of relays per country and total CW per country (as you suggested previously). The former stastic could be used for badges like "First relay in country X."
More than 4/5 of the family's CW is located in countries with a cw lower than 2%* (currently means non-top 7 country) and ASes lower than 1.5%* (currently means non-top 8 AS)?
That implies some degree of in-family diversity since a big family would have to spread across multiple countries/ASes
Although there have been some interesting discussions about which ASes to prioritize in putting new relays, an actual concrete numerical measure is thus far an unsolved problem. Virgil and I have talked about using a new tool (http://labs.apnic.net/vizas/) to observe which ASes have more interconnections and award bonus points to new relays on them. When these measures become better established definitely in favor of making badges for them (perhaps even replacing the within-operator diversity badges?).
"No Self-Referencing Relays" I'm not sure what exactly you mean by that but I assume it is a MyFamily config where a relay includes his own fingerprint. Why does that hurt? The unnecessary descriptor space/bw?
This is something Virgil wanted because he thought self-connections were ugly. If the penalizing of self-connections is found to be uglier than the self-connections themselves, we're both fine with removing it.
Hope this answers your questions. Thanks for the feedback!
Best, Sean
On 13 Sep 2015, at 18:18, Sean Saito saitosean@ymail.com wrote:
"No Self-Referencing Relays"
I'm not sure what exactly you mean by that but I assume it is a MyFamily
config where a relay includes his own fingerprint. Why does that hurt?
The unnecessary descriptor space/bw?
This is something Virgil wanted because he thought self-connections were ugly. If the
penalizing of self-connections is found to be uglier than the self-connections themselves, we're
both fine with removing it.
Can this be downgraded to an informational message? (or eliminated entirely?)
Penalties can be quite discouraging, particularly for minor configuration variants.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5
teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7
On 13 Sep 2015, at 22:09, teor teor2345@gmail.com wrote:
On 13 Sep 2015, at 18:18, Sean Saito saitosean@ymail.com wrote:
"No Self-Referencing Relays"
I'm not sure what exactly you mean by that but I assume it is a MyFamily
config where a relay includes his own fingerprint. Why does that hurt?
The unnecessary descriptor space/bw?
This is something Virgil wanted because he thought self-connections were ugly. If the
penalizing of self-connections is found to be uglier than the self-connections themselves, we're
both fine with removing it.
Can this be downgraded to an informational message? (or eliminated entirely?)
Penalties can be quite discouraging, particularly for minor configuration variants.
Tim
I agree, and this one in particular is important to some operators: by allowing a relay to specify itself in the family, one can just have a single configuration file for all relays in a family.
Tom
We'll remove it.
-V
On Mon, 14 Sep 2015 at 05:20 Tom van der Woerdt info@tvdw.eu wrote:
On 13 Sep 2015, at 22:09, teor teor2345@gmail.com wrote:
On 13 Sep 2015, at 18:18, Sean Saito saitosean@ymail.com wrote:
"No Self-Referencing Relays"
I'm not sure what exactly you mean by that but I assume it is a MyFamily
config where a relay includes his own fingerprint. Why does that hurt?
The unnecessary descriptor space/bw?
This is something Virgil wanted because he thought self-connections were ugly. If the
penalizing of self-connections is found to be uglier than the self-connections themselves, we're
both fine with removing it.
Can this be downgraded to an informational message? (or eliminated entirely?)
Penalties can be quite discouraging, particularly for minor configuration variants.
Tim
I agree, and this one in particular is important to some operators: by allowing a relay to specify itself in the family, one can just have a single configuration file for all relays in a family.
Tom
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Sun, Sep 13, 2015 at 11:20:11PM +0200, Tom van der Woerdt wrote:
I agree, and this one in particular is important to some operators: by allowing a relay to specify itself in the family, one can just have a single configuration file for all relays in a family.
Maybe somebody wants to make a trac ticket pointing to this thread, and suggesting that Tor should notice when it's about to list its own fingerprint in its family line, and just quietly leave it out?
I bet that would be an easy minor feature for somebody to add, and it would avoid creating this confusion in the future.
--Roger
On 15 Sep 2015, at 08:34, Roger Dingledine arma@mit.edu wrote:
On Sun, Sep 13, 2015 at 11:20:11PM +0200, Tom van der Woerdt wrote:
I agree, and this one in particular is important to some operators: by allowing a relay to specify itself in the family, one can just have a single configuration file for all relays in a family.
Maybe somebody wants to make a trac ticket pointing to this thread, and suggesting that Tor should notice when it's about to list its own fingerprint in its family line, and just quietly leave it out?
I bet that would be an easy minor feature for somebody to add, and it would avoid creating this confusion in the future.
—Roger
https://trac.torproject.org/projects/tor/ticket/17065 https://trac.torproject.org/projects/tor/ticket/17065
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
Hi,
roster's recommended tor version check seems broken, example:
http://tor-roster.org/family_detail/963ADC0137505151C1AFA6757DD2367EDEEC7B62
Runs Recommended Tor Version For All Relays: false
but all relays run 0.2.4.27 - which is currently a 'recommended version' as per https://consensus-health.torproject.org/#recommendedversions
Why does that family has a exit bw badge if it doesn't provide any exit relays?
Displaying guard probability would be nice.
Do you consider in-family diversity so important - even though all of them are run by a single entity anyway? How about having a badge for tor network wide diversity? I'd consider the tor network's overall diversity far more important than in-family diversity because clients won't use more than one relay of a given family anyway.
Entire-network diversity is obviously more important than within-operator diversity---no doubt about that. We are doing within-operator diversity simply because the it's easier to measure/understand. I agree that measuring a family's relay diversity with respect to the entire Tor network is would be supplementary, maybe even strictly better. I am already logging relevant data, namely the number of relays per country and total CW per country (as you suggested previously). The former stastic could be used for badges like "First relay in country X."
More than 4/5 of the family's CW is located in countries with a cw lower than 2%* (currently means non-top 7 country) and ASes lower than 1.5%* (currently means non-top 8 AS)?
That implies some degree of in-family diversity since a big family would have to spread across multiple countries/ASes
Although there have been some interesting discussions about which ASes to prioritize in putting new relays, an actual concrete numerical measure is thus far an unsolved problem. Virgil and I have talked about using a new tool (http://labs.apnic.net/vizas/) to observe which ASes have more interconnections and award bonus points to new relays on them. When these measures become better established definitely in favor of making badges for them
How about keeping it simple? "All relays run in countries with a CW fraction < 5%" ?
you could simply use compass output.
(perhaps even replacing the within-operator diversity badges?).
Yes, please.
-
nusenu -
Roger Dingledine -
Sean Saito -
teor -
Tim Wilson-Brown - teor
-
Tom van der Woerdt -
Virgil Griffith