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