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:00<https://exonerator.torproject.org/consensus?valid-after=2014-02-25-00-00-00> r phillw tNrlqRlQkVqUXVGLWFYhQeYBYI0 pR9ddClTA2Eo6AI989NA3BGXNs4<https://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 <[email protected]> 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 > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > -- https://wiki.ubuntu.com/phillw
_______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
