Hi,
I'm trying to follow this, so perhaps if someone could explain a little bit to me.... metrics reports.....
valid-after 2014-02-25 00:00:00https://exonerator.torproject.org/consensus?valid-after=2014-02-25-00-00-00 r phillw tNrlqRlQkVqUXVGLWFYhQeYBYI0 pR9ddClTA2Eo6AI989NA3BGXNs4https://exonerator.torproject.org/serverdesc?desc-id=a51f5d742953036128e8023df3d340dc119736ce 2014-02-24 14:29:23 176.31.156.199 9001 0 s Fast Guard Named Running Stable Valid v Tor 0.2.4.20 w Bandwidth=7530 p reject 1-65535
I'm guessing that the cut off level proposed is 'Bandwidth'... to what level would it fall before said relay was not used with guard, or am I totally wrong in my thoughts of what is being proposed?
Regards,
Phill.
On 25 February 2014 04:51, Tariq Elahi tariq.elahi@uwaterloo.ca wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hey George, Glad to see that guard questions are still being asked. Some thoughts from your plots.
On 24-Feb-14 9:06 PM, George Kadianakis wrote:
And because release-early-release-often, here is a graph: https://people.torproject.org/~asn/guards/guard_boxplot_4000.png
The middle boxplot is the probability distribution of our current guard selection process (e.g. the most likely to be selected guard node is selected with probability ~0.013). The right boxplot is the probability distribution we would have if we pruned the guard nodes that are slower than 4MB/s. We can see that in that case, the most popular guard node has probability of ~0.15 being selected.
A question: How much of the total BW was dropped due to the condition "guard BW must be greater than 4MB"?
- From a security perspective:
While the top guard did get ~0.015 rather than ~0.013, a change of +~15% on its original probability of being selected, all the other guards also got a boost. Thinking about it from a steady state: the increase in chance (+X%) of being picked is due to the fact that they _do_ now own +X% more bw than before. They haven't gained something for nothing. So it seems that dropping bandwidth is not harmful if we forget about the previous state of the network.
Have I got something wrong in this analysis?
Other thoughts: raising the bar on guards leads to good things(tm). Not amazing(R), though. One, you get less relays that shouldn't really be guards slowing things down. Two, an adversary can't take control of a large number of slow relays (like in a botnet of residential computers) and run guards that in aggregate give them a lot of bandwidth (which is how guards are selected, i.e. the adversary gets one of their bots picked because the chance of one of the bots being picked in aggregate is high) and at the same time slow down service for a client who actually will use that bad guard with low bandwidth. The trick, as you have pointed out, is in picking this cut-off point. But dropping the bottom most doesn't really hurts things, apart form the feeling of leaving bandwidth on the table.
Looking forward to seeing progress. :)
Cheers, Tariq -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTDCFnAAoJEJaS+qOeq5CkB1QH/2Elbogxn4jY54fi69UxT4lp hgRBSrYJwVH41SqmIe+pZgKk0R6SvLMK3UQiEMKGqH/ah25uR18KBV+g/t57gXzm hI/u/tXophbF6fIk+EnA1PdYgyFsF3fPoxieT4HHvsui/y/Xadt49reRBrE209I0 /uMT1yIWDv24Hr03HQz2vFX8EXM/L0veBnbBjH9BvHWa2+bEKnYd/RdY/+4BLHY6 jfi6/eqOSgvRGgazSuepH3sNUJ2s9OtvOVtp33I8WX90QVW+UWPwXeozNi3m9PSg p8CYHiL4VhBcM3ttj39U15s4Z1jKW/c1bUnb+AkGxdCVEqTPT3aONGegv2EbTvo= =GsDo -----END PGP SIGNATURE----- _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev